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pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
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Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Conmiittee Electronic Signatures and 
Infrastructures (ESI). 

The present document is part 2 of a multi-part deliverable. Full details of the entire series can be found in part 1 [i.2]. 



Introduction 



Business and administrative relationships among companies, public administrations and private citizens, are the more 
and more implemented electronically. Trust is becoming essential for their success and continued development of 
electronic services. It is therefore important that any entity using electronic services have suitable security controls and 
mechanisms in place to protect their transactions and to ensure trust and confidence with their partners. 

Electronic mail is a major tool for electronic business and administration. Additional security services are necessary for 
e-mail to be trusted. At the time of writing the present document, in some European Union Member States (Italy, 
Belgium, etc.) regulation(s) and application(s) are being developed, if not already in place, on mails transmitted by 
electronic means providing origin authentication and proof of delivery. A range of Registered E-Mail ("REM") services 
is already established and their number is set to grow significantly over the next few years. Without the definition of 
common standards there will be no consistency in the services provided, making it difficult for users to compare them. 
Under these circumstances, users might be prevented from easily changing to alternative providers, damaging free 
competition. Lack of standardization might also affect interoperability between REM based systems implemented based 
on different models. The present Technical Specification is to ensure a consistent form of service across Europe, 
especially with regard to the form of evidence provided, in order to maximize interoperability even between e-mail 
domains governed by different policy rules. 

In order to move towards the general recognition and readability of evidence provided by registered e-mail services, it is 
necessary to specify technical formats, as well as procedures and practices for handling REM, and the ways the 
electronic signatures are applied to it. In this respect, the electronic signature is an important security component to 
protect the information and to provide trust in electronic business. It is to be noted that a simple "electronic signature" 
would be insufficient to provide the required trust to an information exchange. Therefore the present Technical 
Specification assumes the usage of at least an Advanced Electronic Signature, with the meaning of article 2(2) of EU 
Directive 1999/93/EC [1] issued with a Secure Signature Creation Device, with the meaning of article 2(6) of the same 
Directive. 
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1 Scope 



The basic purpose of a Registered E-Mail service is to provide users, in addition to the usual services supplied by the 
ordinary e-mail service providers, with a set of evidence suitable to uphold assertions of acceptance (i.e. of "shipment"), 
of delivery/non delivery, of receipt, etc. of e-mails sent/delivered through such service. 

The present document provides: 

a) Rules for building a REM-MD Envelope and, consequently, a REM Dispatch or a REM-MD Message. 

b) Syntax and semantics of REM-MD Evidence to be produced by a REM Management Domain. 

c) Rules on the signature to be used within REM-MD Envelopes. 

REM-MD Evidence formats are deemed to comply with legal, regulatory or contractual requirements to provide legal 
validity and enforceability under domestic or international law. 

The structure of the present document is as follows: 

Clause 2 contains the list of normative and informative references. 

Clause 3 includes definitions of the relevant concepts to the present document and abbreviations. 

Clause 4 contains the generic REM-MD Envelope structure. 

Clause 5 contains the definition of REM-MD Evidence produced by REM-MDs, in terms of content and 
semantics. Specific syntaxes are addressed by annexes. 

Clause 6 deals with digital signatures to be applied by REM-MD for building REM-MD Envelopes. 

Clause 7 deals with the implementation of aTSL based mechanism for allowing mutual trust of REM-MDs. 

Annex A provides ASN.l syntax for REM-MD Evidence. 

Annex B provides xml syntax for REM-MD Evidence. 

Annex C provides PDF syntax for REM-MD Evidence. 

Annex D specifies identifiers and codes for reporting events reasons in REM-MD Evidence. 

Annex E provides the ASN. 1 definition for REM-MD Evidence encoded in ASN. 1 . 

Annex F provides the XML schema for REM-MD Evidence encoded in XML. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 
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Referenced documents which are not found to be pubHcly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[I] Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a 
Community framework for electronic signatures. 

[2] IETF RFC 3852: "Cryptographic Message Syntax (CMS)". 

[3] ETSI TS 101 733: "Electronic Signatures and Infrastructures (ESI); CMS Advanced Electronic 

Signatures (CAdES)". 

[4] ETSI TS 101 903: "XML Advanced Electronic Signatures (XAdES)". 

[5] ETSI TS 102 176-1: "Electronic Signatures and Infrastructures (ESI); Algorithms and Parameters 

for Secure Electronic Signatures; Part 1: Hash functions and asymmetric algorithms". 

[6] ETSI TS 102 231: "Electronic Signatures and Infrastructures (ESI); Provision of harmonized 

Trust- service status information" . 

[7] W3C Recommendation: "XML Signature Syntax and Processing". 

[8] IETF RFC 3851: "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message 

Specification". 

[9] IETF RFC 2822: "Internet Message Format" . 

[10] ITU-T Recommendations X.680-683: "Information technology - Abstract Syntax Notation One 

(ASN.l)". 

[II] ITU-T Recommendation X.690: "Information technology - ASN.l encoding rules: Specification of 
Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding 
Rules (DER)". 

[12] OASIS Digital Signature Services (DSS) TC: "Digital Signature Service Core Protocols, Elements, 

and Bindings Version 1.0". 

[13] IETF RFC 3061 (2001): "A URN Namespace of Object Identifiers". 

[14] IETF RFC 5280: "Internet X.509 Pubhc Key Infrastructure Certificate and Certificate Revocation 

List (CRL) Profile". 

[15] AFNOR AC Z74-600-3 (2005): "Electronic attestations of anteriority, deposit, withdrawal and 

receipt - Part 3 : format of attestations". 

[16] ETSI TS 102 904: "Electronic Signatures and Infrastructures; Profiles of XML Advanced 

Electronic Signatures based on TS 101 903 (XAdES)". 

[17] ETSI TS 102 778: "Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic 

Signature Profiles". 

[18] ETSI TS 102 778-2: "Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic 

Signature Profiles; Part 2: PAdES Basic - Profile based on ISO 32000-1". 

[19] ETSI TS 102 778-3: "Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic 

Signature Profiles; Part 3: PAdES Enhanced - PAdES-BES and PAdES-EPES Profiles". 
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2.1 Informative references 



The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TR 102 605: "Electronic Signatures and Infrastructures (ESI); Registered E-Mail". 

[i.2] ETSI TS 102 640-1: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 1: Architecture". 

[i.3] ETSI TS 102 640-3: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 3: Information Security Policy Requirements for REM Management Domains". 

[i.4] Void. 

[i.5] Void. 

[i.6] IETF RFC 2045: "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet 

Message Bodies". 

[i.7] IETF RFC 2046: "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types". 

[i.8] Void. 

[i.9] Void. 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TS 102 640-1 [i.2] apply. 
Throughout the present document a number of verbal forms are used, whose meaning is defined below: 

• shall, shall not: indicate requirements strictly to be followed in order to conform to the present document and 
from which no deviation is permitted. 

• should, should not: indicate that among several possibilities one is recommended as particularly suitable, 
without mentioning or excluding others, or that a certain course of action is preferred but not necessarily 
required, or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited. 

• may, need not: indicate a course of action permissible within the limits of the present document. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TS 102 640-1 [i.2] and the following apply: 

OID Object Identifier 

QES Qualified Electronic Signature 

R-REM-MD Recipient's REM-MD 

S-REM-MD Sender's REM-MD 

TrST Trust Service Token 

NOTE: As per TS 102 231 [6]. 

URI Uniform Resource Identifier 
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4 REM-MD Envelope Structure Implementation 

This clause provides a specification for the structure of a REM-MD Envelope. A REM-MD Envelope does not exist as 
a self-standing object, since it always appear in the context of a REM-MD Message or a REM Dispatch. 

A REM-MD Message or a REM Dispatch may flow between REM-MDs, and optionally from REM-MDs to REM User 
Agents, as defined in TS 102 640-1 [i.2]. No specifications are provided in the present document on how the generic 
REM-MD Message or REM Dispatch should be tailored according to the specific mode of operation and interface it 
flows through. 

A REM-MD Envelope is a structure for encapsulating REM-MD Evidence and/or Original Message. Moreover it 
contains: 

1) An (optional) introductory message-part displayed by the mail client application and in which the REM-MD 
explains the purpose of the current message and gives some details on the other parts attached to it. The actual 
message may also contain references to objects stored in a REM-MD Repository. 

2) A signature applied by the REM-MD (the signature covers both the Original Message, when present, and the 
REM-MD Evidence). 



A REM-MD Envelope is structured with a Message Header containing the Header Fields followed by Message Body 
containing one or more Body Parts as defined in MIME (RFC 2045 [i.6]). The Message Body will take the form of a 
multipart/mixed MIME structure in which every MIME-body-part contains one of the aforementioned elements (except 
the signature element). This multi-part/mixed MIME message will constitute the signed MIME-body-part of a 
multipart/signed S/MIME message. The S/MIME signature contained in the last MIME part of the REM-MD Envelope 
will therefore be the signature of the REM-MD over the rest of the MIME parts that appear in the REM-MD Envelope 

This generic structure with all its elements can be further depicted in figure 1 . 
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Optional full, self-contained RFC 822 message as submitted by the 
sender, (the Original Message). Only present in REM Dispatch 



MIME part headers profiled for application/xml (see clause 4.7) 



Optional xml attachment to be used by possible extensions 



MIME part headers profiled for an application/octet-stream, 
application/xml or application/pdf (see clause 4.7) 



Optional REM-MD Evidence as required by the specific content- 
type 



MIME part headers profiled to S/MIME application/pkcsT-signature signature on 
the whole REM-MD Message/REM Dispatch (see clause 4.3) 



S/MIME Signature generated by the Sender's REM-MD covering the whole structure 



Figure 1 : REM-MD Envelope generic template 

Figure 1 presents the full structure including parts in grey which should be present in a REM Dispatch or a 
REM-MD Message. 

The following clauses will aim at further profiling/constraining each headers of this generic message structure. 
The present document does not impose any constraint on those headers fields not listed in the tables below. 



4.1 REM-MD Message/REM Dispatch Headers constraints 



Content-Type 


The value for this header shall be "multipart/signed". 

The 'protocol' parameter value shall be "application/pkcs7-signature". 

The 'micalg' parameter value should be conformant to TS 102 176-1 [5] 


IVIIIVIE-Version 


The value for this header shall be "1 .0". 


IVIessage-ID 


This value should be an UID as defined in RFC 2822 [9]. 


Date 


This value shall be compliant with clause 3.3 of RFC 2822 [9]. 


From 


This value should be either a REM-MD service address 

(e.Q. "<service rem md x(a)rem md x.com>" or a transformation of the oriainal 

From field to show the role of the REM-MD (e.g. "on behalf of 

user(a)rem md x.com <service rem md x(a)rem md x.com>"). 


To 


This value shall be compliant with clause 3.6.3 of RFC 2822 [9]. The value for 
this header shall match the value of the 'To' header field in the Original 
Message. 


Subject 


This value should be transformed starting from the Subject header field 
contained in the original sender's message, in order to indicate the role that the 
REM-MD Message/REM Dispatch has within the flow. (E.g.: "REM Dispatch: 
subject_of_original_message" if the message is an envelope for the original 
sender's message, "REM Delivery Receipt: subject_of_original_message" if the 
REM-MD Message is a delivery receipt). 


Reply-To 


The value for this header shall match the value of the 'From' header field in the 
Original Message. 
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The header of each REM-MD Envelope may contain optional Extension Header Fields. The purpose of these headers is 
to give immediate access to important identification information, which is already present in either the REM-MD 
Evidence or REM-MD message, instead of forcing REM-MDs to go through the REM-MD Evidence 

The syntax of these optional parameters is one of the following: 

X-REM-Msg-Type : <value> 

where <value> shall be : 

• "Dispatch" for a REM Dispatch (i.e. the Original Message by the sender is included) 

• "Message" for any other REM-MD Message (i.e. a return receipt or a message generated by REM-MD 
containing URI references to REM Object or REM-MD Evidence) 

X-REM-<component> : <value> 

where: 

• <component> is a label (possibly related to the name of a REM-MD Evidence Component or subcomponent - 
see clause 5.2). 

• <value> is a correspondent value for the component. 
As an example, the following headers field may be introduced: 

• X-REM-hashAlgorithm: <algorithm used in hash computation> 

• X-REM-hashValue: <sender's Message Hash> 

• X-REM-UAMessageldentifier: < identifier of the original message submitted by the UA> 

4.2 REM-MD Message/REM Dispatch Data Headers 
Constraints 

IContent-Type |The value for this field shall be: "multipart/mixed" I 



4.3 REM-MD Signature Headers Constraints 

The fields defined in the following table and their respective values shall adhere to the sections 3.2.1 and 3.4.3 of RFC 
3851 [8]. 



Content-Type 


The value for this header shall be: "application/pkcs7-signature; 

name=smime.p7s". 

The parameter 'name' should be present and its value should be "smime.p7s". 


Content-Transfer-Encoding 


This header should be present The value for this header shall be: "base64". 


Content-Disposition 


The value for this header shall be: "attachment". 

The value of the 'filename' parameter should be "smime.p7s". 


Content-Description 


The value for this header may be: "S/MIME Cryptographic Signature". 



Even if REM-MDs shall include the field Content-Disposition and fill in the name/filename parameters, REM-MDs 
shall be able to correctly interpret incoming messages without Content-Disposition and/or name/filename parameters. 

4.4 REM-MD Introduction Headers Constraints 



Content-Type 


The value for this field shall be: "multipart/alternative" 


X-REM-Section-Type 


The value of this optional field should be "rem_message/introduction" 
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The order chosen for the following alternative parts finishes with the most preferred choice from the email clients, as 
reported RFC 2046 [i.7] (the best choice is the LAST part of a type supported by the recipient system's local 
environment). 

4.4.1 Multipart/alternative: Free text subsection Header constraints 



Content-Type 


The value for this field shall be: "text/plain". 

The value of the 'charset' parameter should be "UTF-8". 


Content-Disposition 


The value of this header shall be "inline" as it is intended to be displayed 
automatically upon display of the message in mail client. 


Content-Transfer-Encoding 


The value for this field shall be: 7bit. 



4.4.2 Multipart/alternative: Html subsection Header constraints 



Content-Type 


The value for this field shall be: "text/html;". 

The value of the 'charset' parameter should be "UTF-8". 


Content-Transfer-Encoding 


The value for this field should be: 7bit or quoted-printable. 



This "alternative" part shall contain the same information of the Free Text part and the HTML shall not contain active 
code. 

If the present part contains some URL it shall be indicated explicitly in the visible text. The printed part (that is the 
Hypertext visible to the user) shall be the same as the hidden part (that is the real location where the web browser is 
redirected clicking on it). 

4.5 Original Message MIME Section Headers Constraints 



Content-Type 


The value for this field shall be: "message/rfc822"; 

name^AttachedMimeMessage 


Content-Transfer-Encoding: 


7bit 


Content-Disposition 


The value for this field shall be: "attachment"; 

filename=AttachedMime]y[essage 


X-REM-Section-Type 


The value of this optional field should be "rem_message/original". 



This clause contains the Original Message and makes only sense when the message has to be conveyed to the Recipient 
by value (in the Store & Forward Style of operations). 



4.6 



REM-MD Extensions MIME Section Headers Constraints 



Content-Type 


The value for this header will be "application/xml". 

The value of the 'name' parameter will be "REMExtensions.xml". 

The value of the 'charset' parameter shall be "UTF-8". 


Content-Transfer-Encoding 


The value of this header shall be "quoted-printable". 


Content-Disposition 


The value of this header will be "attachment". 

The value of the 'filename' parameter will match the value of the 'name' 

parameter of the Content-Type header. 


X-REM-Section-Type 


The value of this optional field should be "rem message/extension". 


X-REM-Extension-Code 


The value of this optional field is not defined here. It should be in accordance 
with the type of the attachment, in order to allow for automatic processing. 



The structure of this optional attachment is not defined here, since it is left for any possible extensions to be agreed on a 
peer-to-peer basis (e.g. Automatic processing of download URI in S&N style of operation, insertion of Electronic 
PostMark, etc.). 
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4.7 



REM-MD Evidence MIME Section Headers Constraints 



4.7.1 ASN.1 Format 



Content-Type 


The value for this header will be "application/octet-stream" 
The value of the 'name' parameter will be "<REM 
EVIDENCE_NAME>.aso" 

The value of the 'charset' parameter shall be "UTF-8" 


Content-Transfer-Encoding 


The value of this header shall be "quoted-printable" 


Content-Disposition 


The value of this header will be "attachment" 

The value of the 'filename' parameter will match the value of the 
'name' parameter of the Content-Type header 



4.7.2 XML Format 



Content-Type 


The value for this header will be "application/xml" 

The value of the 'name' parameter will be "<REM 
EVIDENCE_NAME>.xml" 

The value of the 'charset' parameter shall be "UTF-8" 


Content-Transfer-Encoding 


The value of this header shall be "quoted-printable" 


Content-Disposition 


The value of this header will be "attachment" 

The value of the 'filename' parameter will match the value of the 
'name' parameter of the Content-Type header 



4.7.3 PDF Format 



Content-Type 


The value for this header will be "application/pdf" 

The value of the 'name' parameter will be "<REM 
EVIDENCE NAME>.pdf" 


Content-Transfer-Encoding 


The value of this header will be "base64" 


Content-Disposition 


The value of this header will be "attachment" 

The value of the 'filename' parameter will match the value of the 
'name' parameter of the Content-Type header 



5 REM-MD Evidence Content and Semantics 

This clause provides the content and semantics for REM-MD Evidence, which are trusted statements produced by 
REM-MDs, according to the flows described in TS 102 640-1 [i.2]. One REM-MD Evidence can address more Events 
among those described individually in TS 102 640-1 [i.2], clause 6. 

In clause 5.1 the list of REM-MD Evidence is presented in detail. 

REM-MD Evidence are described with reference to a set of building blocks called "REM-MD Evidence components". 
In clause 5.2 REM-MD Evidence Components are listed and described in terms of content and semantics. This clause is 
divided in the following three clauses: 

i) Clause 5.2.1 presents a synoptic Template of REM-MD Evidence Components. 

ii) Clause 5.2.2 provides a detailed description and explanation of all REM-MD Evidence Components that are 
described in terms of content and semantics. 

iii) Clause 5.2.3 describes formats and values of the REM-MD Evidence Components, providing elements such as 
Time and Data format. Exception Codes, etc. 

Specific syntaxes allowed for REM-MD Evidence are provided in annexes A, B and C. 
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5.1 



REM-MD Evidence 



In this clause the REM-MD Evidence provided by REM-MD are described. They correspond to events mentioned in 
TS 102 640-1 [i.2], clause 6 as described in the following table. 



Event (TS 102 640-1 [i.2], clause 6.2) 


REM-MD Evidence 


6.2.1 Event A.I - S- REM-MD Acceptance 


5.1 .1 SubmissionAcceptanceRejection 


6.2.1 Event A.2 - S- REM-MD Rejection 


6.2.2 Event B.I - R-REM-MD Acceptance 


5.1 .2 RelayToREMMDAcceptanceRejection 


6.2.2 Event B.2 - R-REM-MD Rejection 


6.2.2 Event B.3 - Expiration of time to deliver to R-REM-MD 


5.1.3 RelayToREMMDFailure 


6.2.3 Event C.I - Message Delivery 


5.1 .4 DeliveryNonDeliveryToRecipient 


6.2.3 Event C.2 - Expiration of time to deliver message 


6.2.3 Event D.I - Notification Delivery 


6.2.3 Event D.2 - Expiration of time to deliver notification 


6.2.3 Event E.I (REM-MD Repository) - Download 


5.1 .5 DownloadNonDownloadByRecipient 


6.2.3 Event E.2 (REM-MD Repository) - Expiration of time for 
download 


6.2.3 Event E.4 (REM-MD Repository) - Download by a 
recipient's delegate 


6.2.3 Event F.I (mailbox) - Retrieval 


5.1 .6 RetrievalNonRetrievalByRecipient 


6.2.3 Event F.2 (mailbox) - Expiration of time for Retrieval 


6.2.3 Event F.3 (mailbox) - Retrieval by a recipient's delegate 


6.2.3 Event E.3 - Rejection of download by recipient 


5.1 .7 AcceptanceRejectionByRecipient 


6.2.4 Event H.I - Successful forwarding for Ordinary e-mail 


5.1.8 RelayToNonREMSystem 


6.2.4 Event H.2 - Unsuccessful forwarding for Ordinary e-mail 


6.2.4 Event G.I - Successful forwarding for Printing 


6.2.4 Event G.2 - Unsuccessful forwarding for Printing 


6.2.4 Event 1.1 - E-Mail message received from a regular 
e-mail system 


5.1.9 ReceivedByNonREMSystem 



In order to facilitate interoperability within the REM community, and based on the outcomes published in 

TR 102 605 [i.l] of a survey performed among a large number of interviewees, each REM-MD Evidence type is 

indicated as "M" (mandatory), "R" (recommended) or "O" (optional). 

A few of these REM-MD Evidence types can be issued by, or with the support of, external providers, therefore, where 
applicable, locutions like "issued under the responsibility of" are used instead of "issued by". 

In the following clauses for each REM-MD Evidence the basic content is specified by means of MANDATORY 
"REM-MD Evidence Components" the content of which is specified in clause 5.2. Additional "REM-MD Evidence 
Components" may be used where applicable, either chosen from those listed in clause 5.2.1, or additional ones 
applicable within a predefined set of REM-MDs, like a REM-PD. 

Parties other than the "Primary REM-MD Evidence Recipient" may also rely on any REM-MD Evidence. 

It should be noted that different forms of REM-MD Evidence may be directly provided by the sender itself, for 
instance by electronically signing the message before sending. This sender's signature provides an additional reliable 
information on the message origin and authenticity, provided that the certificate supporting the signature is issued by a 
Certification Authority that is acknowledged as trusted (see note) and, preferably, that the signature is issued by means 
of a Secure Signature Creation Device with the meaning of article 2(6) of the Directive 1999/93/EC [1]. However, this 
is outside the scope of the present document. 

NOTE: As an example, in the European Union, Certification Authorities issuing Qualified Certificates, as defined 
in the European Directive 1999/93/EC [1] article 2(10), are trusted since article 3(3) of the same Directive 
mandates that they are supervised in the EUMS they reside in. 
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5.1 .1 SubmissionAcceptanceRejection 



Description 


REM-MD Evidence of submitted message acceptance/Rejection 


Optionality 


M 


Purpose 


To prove that a certain Original IVIessage was/was not successfully submitted, at the time 
indicated in the REM-MD Evidence, to the sender's REM-MD by the sender authenticated by the 
same sender's REM-MD. 


Related event 


Successful/unsuccessful acceptance by sender's REM-MD of an Original Message submitted to 
the same REM-MD by the authenticated message sender. 


Responsible for 
Issuance 


Sender's REM-MD. 


Primary Intended 
Recipient 


Message sender and message recipient. 


REM-MD Evidence 
Components 










Id 


Component 


#lter 




GOO 


REM-MD Evidence Identifier 




G01 


REM-MD Evidence Type = "SubmissionAcceptanceRejection" 




G02 


REM Event 




G03 


Reason code 


0..N 


G04 


REM-MD Evidence Version 




G05 


Event Time 




G06 


Transaction log information 


0..N 


R01 


REM-MD Evidence issuer Policy Identifier 


1..N 


R02 


REM-MD Evidence issuer Details 




R03 


Signature by issuing REM-MD 


0..1 


100 


Sender's details 




101 


Recipient's details 


1..N 


104 


Sender Authentication details 


0..1 


MOO 


REM-MD Message/REM Dispatch details 




M01 


Reply-to 




M03 


Message Submission Time 
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5.1 .2 RelayToREMMDAcceptanceRejection 



Description 


REM-MD Evidence that a successfully received REM-MD Message/REM Dispatch was 
accepted/rejected by the recipient's REM-MD. 


Optionality 


It should be sent to the sender's REM-MD. 
It may be sent back to the sender. 


Purpose 


To prove that one REM-MD Message/REM Dispatch sent by the sender's REM-MD was 

successfully received by the recipient's REM-MD that accepted/rejected it. 

NOTE: This REM-MD Evidence is applicable when the received message comes from 

another REM-MD. The case when it comes from an ordinary e-mail server is covered 

in clause 5.1.9. 


Related event 


The REM-MD Message/REM Dispatch was sent by the sender's REM-MD and received by the 
recipient's REM-MD that accepted/rejected it. 


Responsible for 
Issuance 


Recipient's REM-MD. 


Primary Intended 
Recipient 


Sender's REM-MD. 


REM-MD Evidence 
Components 










Id 


Component 


#lter 




GOO 


REM-MD Evidence Identifier 




G01 


REM-MD Evidence Type = 
"RelayToREMMDAcceptanceRejection" 




G02 


REM Event 




G03 


Reason code 


0..N 


G04 


REM-MD Evidence Version 




G05 


Event Time 




G06 


Transaction log information 


0..N 


R01 


REM-MD Evidence issuer Policy Identifier 


1..N 


R02 


REM-MD Evidence issuer Details 




R03 


Signature by issuing REM-MD 


0..1 


100 


Sender's details 




101 


Recipient's details 


1..N 


103 


Recipient referred to by the REM-MD Evidence 




MOO 


REM-MD Message/REM Dispatch details 




M02 


Notification Message Tag 


0..1 


M03 


Message Submission Time 


1 
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5.1 .3 RelayToREMMDFailure 



Description 


REM-MD Evidence of non delivery of a REM-MD Message/REM Dispatch to the recipient's 
REM-MD within a given time period. 


Optionality 


R 


Purpose 


To prove that it was impossible to deliver a REM-MD Message/REM Dispatch within a given time 
period to the recipient's REM-MD due to technical errors and/or other problems. 


Related event 


This REM-MD Evidence can be issued to specify that a problem was encountered when trying to 
forward a REM-MD Message/REM Dispatch to the recipient's REM-MD; the following cases can 
occur: 

1) the sender's REM-MD was not able to identify the recipient's REM-MD; 

2) the recipient's REM-MD is unreachable; 

3) the recipient's REM-MD had malfunctions that prevented the REM-MD Message/REM Dispatch 
delivery. 

The referred to given time period may be set law, by statutory requirements, by internal rules, in 
any case it is reflected in the REM-MD's or in the REM-PD's policies. 


Responsible for 
Issuance 


Sender's REM-MD. 

This REM-MD Evidence is generated by the sender's REM-MD that, where applicable, may take in 

account also the replies from the recipient's REM-MD. 


Primary Intended 
Recipient 


Sender. 


REM-MD Evidence 
Components 




Id 


Component 


#lter 




GOO 


REM-MD Evidence Identifier 




G01 


REM-MD Evidence Type = "RelayToREMMDFailure" 




G02 


REM Event 




G03 


Reason code 


0..N 


G04 


REM-MD Evidence Version 




G05 


Event Time 




G06 


Transaction log information 


0..N 


R01 


REM-MD Evidence issuer Policy Identifier 


1..N 


R02 


REM-MD Evidence issuer Details 




R03 


Signature by issuing REM-MD 


0..1 


100 


Sender's details 




101 


Recipient's details 


1..N 


103 


Recipient referred to by the REM-MD Evidence 




MOO 


REM-MD Message/REM Dispatch details 




M02 


Notification Message Tag 


0..1 


M03 


Message Submission Time 


1 
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5.1 .4 DeliveryNonDeliveryToRecipient 



Description 


REM-MD Evidence of delivery/non delivery within a given time period of a REM-MD 
Message/REM Dispatch to the recipient's or, OPTIONALLY, to a recipient's delegate mailbox 


Optionality 


M 


Purpose 


To prove that the REM-MD Message/REM Dispatch was delivered to the recipient's mailbox or, 
OPTIONALLY, to a delegate's mailbox at a specific time or that it was not possible to deliver it 
within a given time period. This time period can be set in accordance with law, statutory 
requirements or local policy. The rules governing this time period shall be indicated in the 
REM-MD Practice Statement or REM Policy (see part 3). The time period can be any, even zero, in 
which case the recipient's REM-MD will not retry to deliver the REM-MD Message/REM Dispatch if 
the first attempt fails. 

The REM-MD, or REM-PD, policies shall specify if the delivery can be performed into a delegate's 
mailbox and the details of the delegation mechanism and how and for how long the related 
documentation would be kept. 


Related event 


1) The recipient's REM-MD successfully deposited/was not able to deposit within a given time 
period a REM-MD Message/REM Dispatch into the recipient's or, OPTIONALLY, a delegate's 
REM mailbox. In this case the REM-MD that creates this evidence is the recipient's REM-MD. 

2) The sender's REM-MD did not receive within a given time period from the recipient's REM-MD 
a REM-MD Evidence of successful/unsuccessful delivery. In this case it is the sender's 

REM MD that creates this REM-MD Evidence with the suitable reason code. 


Responsible for 
Issuance 


Recipient's REM-MD or sender's REM-MD. 


Primary Intended 
Recipient 


Sender. 


REM-MD Evidence 
Components 




Id 


Component 


#lter 




GOO 


REM-MD Evidence Identifier 




G01 


REM-MD Evidence Type = "DeliveryNonDeliveryToRecipient" 




G02 


REM Event 




G03 


Reason code 


0..N 


G04 


REM-MD Evidence Version 




G05 


Event Time 




G06 


Transaction log information 


0..N 


R01 


Evidence issuer Policy Identifier 


1..N 


R02 


Evidence issuer Details 




R03 


Signature by issuing REM-MD 


0..1 


100 


Sender's details 




101 


Recipient's details 


1..N 


102 


Recipient's delegate details 


0..N 


103 


Recipient referred to by the Evidence 




MOO 


REM-MD Message/REM Dispatch details 




M02 


Notification Message Tag 


0..1 


M03 


Message Submission Time 


1 
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5.1 .5 DownloadNonDownloadByRecipient 



Description 


Evidence of download/non download within a given time period - of a REM-MD 
Message/REM Dispatch by the recipient's or, OPTIONALLY, a recipient's delegate. 


Optionality 


M 


Purpose 


To prove that the REM-MD Message/REM Dispatch at a specific time was downloaded by the 
recipient or, OPTIONALLY, by an Entity Delegated by the Recipient, or non downloaded within a 
given retention period that expired at the specified time. 


Related event 


The recipient or, OPTIONALLY, a delegate successfully downloaded/did not download within a 
given time period a REM-MD Message/REM Dispatch from a REM-MD Repository under the 
responsibility of the sender's or recipient's REM-MD, depending on the download mechanism. 


Responsible for 
Issuance 


Recipient's or sender's REM-MD. 

NOTE: The REM-MD issuing the signature, that is also the REM-MD responsible for the 

RSRI, can be the recipient's REM-MD or of the sender's REM-MD, depending on the 

download mechanism. 


Primary Intended 
Recipient 


Sender. 


REM-MD Evidence 
Components 




Id 


Component 


#lter 




GOO 


REM-MD Evidence Identifier 




G01 


REM-MD Evidence Type = "DownloadNonDownloadByRecipient" 




G02 


REM Event 




G03 


Reason code 


0..N 


G04 


REM-MD Evidence Version 




G05 


Event Time 




G06 


Transaction log information 


0..N 


R01 


Evidence issuer Policy Identifier 


1..N 


R02 


Evidence issuer Details 




R03 


Signature by issuing REM-MD 


0..1 


100 


Sender's details 




101 


Recipient's details 


1..N 


102 


Recipient's delegate details 


0..N 


103 


Recipient referred to by the Evidence 




105 


Recipient Authentication details 


0..1 


MOO 


REM-MD Message/REM Dispatch details 




M03 


Message Submission Time 
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5.1 .6 RetrievalNonRetrievalByRecipient 



Description 


Evidence of retrieval/non retrieval within a given period - by the recipient or, 
OPTIONALLY, by a recipient's delegate 


Optionality 





Purpose 


To prove that the REM-MD Message/REM Dispatch present in the recipient's mailbox was 

retrieved/non retrieved within a given period - by the recipient or, OPTIONALLY, by a recipient's 

delegate. 

Retrieval of the REM-MD Message/REM Dispatch from the mailbox, upon user authentication, 

can be implemented in two ways: 

a) the recipient's (or his/her delegate's) User Agent (a desktop client such as Microsoft Outlook 
or Mozilla Thunderbird), downloads messages from the mailbox at the REM-MD's; 

b) an ad hoc webmail application accesses the related mailbox and messages data, for 
example: sender, subject, send date, size, etc, are fetched and displayed on the webmail 
page; the recipient or his/her delegate is now aware of the REM-MD Message/REM Dispatch 
existence. 


Related event 


The REM-MD Message/REM Dispatch held in the recipient's mailbox is retrieved/not retrieved 
within a given period - by the recipient or, OPTIONALLY, by a recipient's delegate. 


Responsible for 
Issuance 


Recipient's REM-MD. 


Primary Intended 
Recipient 


Sender. 


REM-MD Evidence 
Components 




Id 


Component 


#lter 




GOO 


REM-MD Evidence Identifier 




G01 


REM-MD Evidence Type = "RetrievalNonRetrievalByRecipient" 




G02 


REM Event 




G03 


Reason code 


0..N 


G04 


REM-MD Evidence Version 




G05 


Event Time 




G06 


Transaction log information 


0..N 


R01 


Evidence issuer Policy Identifier 


1..N 


R02 


Evidence issuer Details 




R03 


Signature by issuing REM-MD 


0..1 


100 


Sender's details 




101 


Recipient's details 


1..N 


102 


Recipient's delegate details 


0..N 


103 


Recipient referred to by the Evidence 




105 


Recipient Authentication details 


0..1 


MOO 


REM-MD Message/REM Dispatch details 




M01 


Reply-to 




M02 


Notification Message Tag 


0..1 


M03 


Message Submission Time 


1 
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5.1 .7 AcceptanceRejectionByRecipient 



Description 


Evidence of acceptance/rejection by the recipient, or, OPTIONALLY, a delegate, of a 
REM-MD Message/REM Dispatch. 


Optionality 





Purpose 


To prove that the REM-MD Message/REM Dispatch was accepted/rejected by the recipient or, 
OPTIONALLY, by a delegate. 

This REM-MD Evidence, differently from DownloadNonDownloadByRecipient and 
RetrievalNonRetrievalByRecipient, implies an explicit act of the recipient who declares to 
accept/reject the message. 


Related event 


The recipient or, OPTIONALLY, a delegate communicated to the sender's REM-MD or the 
recipient's REM-MD his/her will to accept/reject a REM-MD Message/REM Dispatch. 
This REM-MD Evidence may apply both to S&N and S&F operation modes. 


Responsible for 
Issuance 


Recipient's REM-MD. 


Primary Intended 
Recipient 


Sender. 


REM-MD Evidence 
Components 




Id 


Component 


#lter 




GOO 


REM-MD Evidence Identifier 


1 


G01 


REM-MD Evidence Type = "AcceptanceRejectionByRecipient" 


1 


G02 


REM Event 


1 


G03 


Reason code 


0..N 


G04 


REM-MD Evidence Version 


1 


G05 


Event Time 


1 


G06 


Transaction log information 


0..N 


R01 


Evidence issuer Policy Identifier 


1..N 


R02 


Evidence issuer Details 


1 


R03 


Signature by issuing REM-MD 


0..1 


100 


Sender's details 


1 


101 


Recipient's details 


1..N 


102 


Recipient's delegate details 


0..N 


103 


Recipient referred to by the Evidence 


1 


105 


Recipient Authentication details 


0..1 


MOO 


REM-MD Message/REM Dispatch details 


1 


M02 


Notification Message Tag 


0..1 


M03 


Message Submission Time 


1 
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5.1 .8 RelayToNonREMSystem 



Description 


Evidence that a REM-MD Message/REM Dispatch was successfully/unsuccessfully 
forwarded to a non-REM external system. 


Optionality 





Purpose 


To prove that a certain REM-MD Message/REM Dispatch was successfully/unsuccessfully 
forwarded by the sender's or recipient's REM-MD to a non REM external system 
Depending on the statutory or contractual agreements, the sender's REM-MD may forward a 
REM-MD Message/REM Dispatch to a non REM external system if it is not able to forward it to 
the recipient's REM-MD via REM. Under similar agreement the recipient's REM-MD may behave 
similarly if it cannot deposit the REM-MD Message/REM Dispatch into the recipient's REM 
mailbox. The involved REM-MD may/may NOT issue REM-MD Evidence types related to the 
various events (e.g. "non delivery" and "forwarding to ordinary e-mail") depending on the 
applicable Policy. 


Related event 


The message was successfully/unsuccessfully forwarded by the sender's or recipient's 
REM-MD to a non REM external system. 


Responsible for 
Issuance 


Sender's or recipient's REM-MD? 


Primary Intended 
Recipient 


Sender. 


REM-MD Evidence 
Components 




Id 


Component 


#lter 




GOO 


REM-MD Evidence Identifier 




G01 


REM-MD Evidence Type = "SubmissionAcceptanceRejection" 




G02 


REM Event 




G03 


Reason code 


0..N 


G04 


REM-MD Evidence Version 




G05 


Event Time 




G06 


Transaction log information 


0..N 


R01 


Evidence issuer Policy Identifier 


1..N 


R02 


Evidence issuer Details 




R03 


Signature by issuing REM-MD 


0..1 


100 


Sender's details 




101 


Recipient's details 


1..N 


102 


Recipient's delegate details 


0..N 


103 


Recipient referred to by the Evidence 




105 


Recipient Authentication details 


0..1 


MOO 


REM-MD Message/REM Dispatch details 




M01 


Reply-to 




M02 


Notification Message Tag 


0..1 


M03 


Message Submission Time 




M04 


Forwarded to external system 
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5.1 .9 ReceivedFromNonREMSystem 



Description 


Evidence that a message was successfully received from a regular (i.e. non REM) e-mail 
system. 


Optionality 





Purpose 


To prove that a certain message was not received from a REIVI-IVID but from an ordinary e-mail 

server, therefore all information on message origin is not per se trustable. 

This REM-MD Evidence will most likely be merged in the REM-MD Message/REM Dispatch that 

the recipient's REM-MD SHALL generate. 

NOTE: This REM-MD Evidence is generated when the message comes from an ordinary 

e-mail server and the recipient's REM-MD policy provides accepting ordinary e-mails 

sent to its own users. 


Related event 


The REM-MD received the message from a regular e-mail gateway. 


Responsible for 
Issuance 


Recipient's REM-MD 


Primary Intended 
Recipient 


Recipient 


REM-MD Evidence 
Components 


All information related to sender and other recipients, in addition to the one this Evidence is 

delivered, is simply claimed by the sender, being not a REM-MD Message/REM Dispatch. 

It is recommended that the REM-MD Message or REM Dispatch including such evidence 

contains in the REM-MD Introduction a disclaimer like the following: 

"On YYYY-MM-DD at hh:mm:ss (+ECT) the message having as subject "<original_subject>" 

was received, seeminalv sent from address "xxxx(a)vvv.zz". 

The REM-MD issuing this REM Dispatch takes commitment only on the time this message was 

received and that the information displayed in the attached Evidence have been transposed from 

the original message without any change. No other commitment is taken by the REM-MD." 




Id 


Component 


#lter 




GOO 


REM-MD Evidence Identifier 




G01 


REM-MD Evidence Type = "SubmissionAcceptanceRejection" 




G02 


REM Event 




G03 


Reason code 


0..N 


G04 


REM-MD Evidence Version 




G05 


Event Time 




G06 


Transaction log information 


0..N 


R01 


Evidence issuer Policy Identifier 


1..N 


R02 


Evidence issuer Details 




R03 


Signature by issuing REM-MD 


0..1 


100 


Sender's details 




101 


Recipient's details 


1..N 


103 


Recipient referred to by the Evidence 




MOO 


REM-MD Message/REM Dispatch details 




M01 


Reply-to 





5.2 REM-MD Evidence Components 
5.2.1 REM-MD Evidence Components Template 

This clause provides a generic template for REM-MD Evidence Components. 

Applications that implement REM-MD functions shall process for each REM-MD Evidence the components indicated 
in clause 5.1 and may process other components. 



ETSI 



25 



ETSI TS 102 640-2 V2.1.1 (2010-01) 



8 

C 
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LU 
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LU 


Component Class 


Id 


Component 


c 

0) 

c 
o 

Q. 

E 
o 

O 

S> 
o 
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GOO 


REM-MD Evidence Identifier 


G01 


REIVI-IVID Evidence Type 


G02 


REM Event 


G03 


Reason code (see note) 

NOTE: Preferably there would be only one (when applicable) G03 listing all 

remarked exceptions reason codes, but it cannot be excluded that one 

single message collects more than one G03. 


G04 


REM-MD Evidence Version 


G05 


Event Time 


G06 


Transaction log information 


REM- 

MD 

Compo 

nents 


R01 


Evidence issuer Policy Identifier 


R02 


Evidence issuer Details 


R03 


Signature by issuing REM-MD 


Identity Related 
Components 


100 


Sender's details 


101 


Recipient's details 


102 


Recipient's delegate details 


103 


Recipient referred to by the Evidence 


104 


Sender Authentication details 


105 


Recipient Authentication details 


Messaging 
Components 


MOO 


REM-MD Message/REM Dispatch details 


M01 


Reply-to 


M02 


Notification Message Tag 


M03 


Message Submission Time 


M04 


Forwarded to external system 


Extended 


Enn 


Space for private or public extensions to be added in the future by a set of users 
or by standardization bodies 



Figure 2: REM-MD Evidence generic template 

Private or public Components, as well as additional Groups, may be added as extensions by a set of users or by standard 
bodies. These Components SHALL not be CRITICAL outside the relevant domain. 

5.2.2 Components description 

5.2.2.1 Core Components 

5.2.2.1 .1 GOO - REM-MD Evidence Identifier 



Description 


This field specifies a unique identifier for REIVI-IVID Evidence within the issuing REM-MD. 


Format 


Text. 


Meaning 


Used to keep track of issued REM-MD Evidence, for possible later retrieval. 


Usage Requirements 





5.2.2.1 .2 G01 - REM-MD Evidence Type 



Description 


This field specifies the type of the REM-MD Evidence. The evidence type shall be 
unambiguously identified. 


Format 


The identification of the type of evidence strongly depends on the syntax selected for encoding 
such evidence. Annexes A, B and C specify formats for evidence in different syntaxes and 
provide details on how this identification is performed. 


Meaning 


The REM-MD Evidence belongs to the given type. 


Usage Requirements 
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5.2.2.1.3 G02 - REM Event 



Description 


This field specifies the REIVI event (as in TS 102 640-1 [i.2], clause 6.2) in front of which the 
REM-MD Evidence has been issued. 


Format 


The identification of the event reported by the evidence strongly depends on the syntax selected 
for encoding such evidence. Annexes A, B and C specify formats for evidence in different 
syntaxes and provide details on how this identification is performed. 
Values from table in clause 5.2.3.2. 


IVIeaning 


The event belongs to the given type. 


Usage Requirements 





5.2.2.1 .4 G03 - Reason code 



Description 


This field indicates a Reason code for further specifying the event which caused the issuance of 
the REM-MD Evidence. 


Format 


The identification of the reason reported by the evidence strongly depends on the syntax 
selected for encoding such evidence. Annex D shows a table with the encodings of the identified 
reasons for the different syntaxes. 
Values from table in clause 5.2.3.3. 


IVIeaning 


Reason code(s) are typically associated to a negative event (failure to deliver, rejection, ...) 
Reason Codes specified in clause 5.2.3.3. Reason clauses are to be used. 
Absence of Reason code means by default a positive event. 


Usage Requirements 


A single REM-MD Evidence may allow for more reason code components. 



5.2.2.1 .5 G04 - REM-MD Evidence Version 



Description 


This field specifies the version of the standard to which the REM-MD Evidence adheres. 


Format 


Text. 


Meaning 


Used to keep track of REM-MD Evidence version. 


Usage Requirements 


A reference to the relevant ETSI standard version should be used. 



5.2.2.1 .6 G05 - Event Time 



Description 


This field specifies the time on which the REM-MD Evidence has been produced by the 
REM-MD. 


Format 


DATE TIME. 


Meaning 


Date and time when the REM-MD Evidence has been produced. 


Usage Requirements 





5.2.2.1 .7 G06 - Transaction log information 



Description 


This field contains the log of the transaction, specific to the transport protocol, regarding the 
event to which the containing REM-MD Evidence refers to. 


Format 


Free text, depending on the applicable Policy. 


Meaning 


This field contains a list of log records related to the implementation of the event addressed by 
the containing REM-MD Evidence. These records are the ones required by, and are formatted 
as per, the applicable Policy. 


Usage Requirements 


If more Policies are to be complied with, each requiring a specific log content and format, 
multiple instances of G06 are possible. 
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5.2.2.2 REM-MD Components 

5.2.2.2.1 R01 - Evidence issuer Policy Identifier 



Description 


This field specifies the Identifier of one Policy that applies to the related REM-MD Evidence 
issuance. 


Format 


One of the widespread formats used for identification: OID or URI. 


IVIeaning 


This field indicates the Identifier of the Policy under which the REM-MD operates. It may be a 
Policy common to an entire REM Policy Domain, or a Policy specific to the related REM-MD, or 
any other applicable Policy. 


Usage Requirements 


Multiple instances of G04 are possible where more Policies are applicable to the REM-MD 
Evidence at issue, for example: 

1) a REM-PD Policy; 

2) a REM-MD specific Policy; 

3) a Policy applicable to the exchange of REM-MD Messages/REM Dispatches between the 
issuing REM-MD and the REM-MD to the environment of which the REM-MD Evidence will 
be forwarded. 



5.2.2.2.2 R02 - Evidence Issuer Details 



Description 


This field specifies several details of the REM-MD Evidence issuer. 


Format 


Structured. 


IVIeaning 


REM-MD Evidence Issuer Commercial information, like commercial name, address, etc. 


Usage Requirements 


This name shall be the one under which the Sender's REM-MD is registered at the relevant 
Authority, be it the Chamber of Commerce or the Authority governing the REM-PD. 



5.2.2.2.3 R03 - Signature by issuing REM-MD 



Description 


If present, this field contains the Signature issued on the REM-MD Evidence under the 
responsibility of the REM-MD. 


Format 


Details provided in clause 6 REM Signatures. 


Meaning 


Signature issued by the REM-MD or its provider on the REM-MD Evidence. 


Usage Requirements 


1) This signature on the REM-MD Evidence, where present, would be additional to the S/MIME 
signature over the entire REM-MD Message/REM Dispatch that SHALL always be present. It 
is required if the REM-MD Evidence is to be exhibited separately from the REM-MD 
Message/REM Dispatch it belongs to. 

2) If this signature is generated by an external provider on behalf of the REM-MD, in the signing 
certificate either the subject SHALL specify the related REM-MD, or an extension SHALL 
assert that the signature was issued by the Provider on behalf of that REM-MD. In other 
words a reliable information on what is the REM-MD responsible for the issuance of the 
evidence SHALL be specified. 

3) The signature format can be any of the above, thus the REM-MD application that receives a 
REM-MD Evidence SHALL be able to handle all of them. 
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5.2.2.3 Identity Components 



5.2.2.3.1 100 - Sender's details 



Description 


This field specifies the Sender's details. 


Format 


structured. 


IVIeaning 


Sender's mailbox identifier and any other information related to sender's identity as defined in 

the applicable Policy Identifier. 

Includes: 

• Electronic address (mandatory). 

• Postal address (optional). 

• Digital certificate info (optional). 

• Signature detail (optional). 


Usage Requirements 


The sender's identity will be provided as defined in the Policy the related REM-MDs, or REM-PD, 
abide by. For example it can be name and surname, or social security ID, or fiscal code. 
The mailbox identifier should be the one under which the sender has been authenticated by the 
REM-MD at issue. 



5.2.2.3.2 101 - Recipient's details 



This field specifies the recipient's details. 



Description 



Format 



Structured. 



IVIeaning 



recipient's mailbox identifier and any other information related to recipient identity as defined in 

the applicable Policy Identifier. 

Includes: 

• Electronic address (mandatory). 

• Postal address (optional). 

• Digital certificate info (optional). 

• Signature detail (optional). 



Usage Requirements 



The recipient's identity will be provided as defined in the Policy the related REM-MDs, or 

REM-PD, abide by. For example it can be name and surname, or social security ID, or fiscal 

code. 

At least one 101 component is present in each evidence, even if delegate recipient is present. 

The mailbox identifier should be the one under which the recipient has been authenticated by 

the REM-MD at issue. 



5.2.2.3.3 102 - Recipient's delegate details 



Description 


This field specifies the recipient's delegate details. 


Format 


Structured. 


Meaning 


In case the recipient's REM-MD allows for delegation, this component will be used to provide 
recipient's delegate mailbox identifier and any other information related to recipient's delegate 
identity as defined in the applicable Policy Identifier. 
Includes: 

• Electronic address (mandatory). 

• Postal address (optional). 

• Digital certificate info (optional). 

• Signature detail (optional). 


Usage Requirements 


The recipient's delegate identity will be provided as defined in the Policy the related REM-MDs, 

or REM-PD, abide by. For example it can be name and surname, or social security ID, or fiscal 

code. 

The mailbox identifier should be the one under which the recipient has been authenticated by 

the REM-MD at issue. 
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5.2.2.3.4 103 -Recipient referred to by the Evidence 



Description 


This component indicates the REIVI-IVID IVIessage/REIVI Dispatch recipient, among the various 
ones indicated via 103, the REIVI-IVID Evidence refers to. 


Format 


Integer. 


IVIeaning 


When several recipients are defined in the REM-MD Evidence (several 103 components will be 
present), this component is used to indicate which of them is the one the REM-MD Evidence 
refers to. 


Usage Requirements 





5.2.2.3.5 104 - Sender Authentication details 



Description 


Information on Sender's authentication. 


Format 


Structured. 


IVIeaning 


This component provides information on sender's authentication, including authentication 
mechanism. 


Usage Requirements 


Represent the following classes of authentication: 

a) Basic: Using basic authentication mechanisms such as passwords. The user may 
authenticate using passwords if protected and only used with an authenticated server, (e.g. 
using TLS/SSL); or 

b) Enhanced: Using enhanced authentication such two factor authentication mechanisms linked 
to a one time password; or 

c) AdES: Using advanced electronic signatures; or 

d) AdES-Plus: Using advanced electronic signatures issued by means of Secure Signature 
Creation Devices (as defined in Directive 1999/93/EC [1]) or equivalent secure cryptographic 
device to recognised standards such as given in part 3 clause 6.4.3; 

e) QES: Using advanced electronic signatures issued by means of Secure Signature Creation 
Devices and supported by Qualified Certificates (as defined in Directive 1999/93/EC [1]). 

NOTE: See also TS 1 02 640-3 [i.3], clause 6.3 on "Sender/Recipient Authentication". 

The default class of authentication is a) Basic. 

In case authentication mechanism has value of c), d) e) the sender's PKCS#7 detached (*.p7s) 

shall be present. 

In case authentication mechanism has value a) the sender's UID may be added. 

Extensibility fields may be used to enable the REM-MD to include any. 

other relevant details of the authentication used. 
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5.2.2.3.6 105 - Recipient Authentication details 



Description 


Information on recipient's authentication. 


Format 


Structured. 


IVIeaning 


This component provides information on recipient's authentication, including authentication 
mechanism. Recipient authentication details refer either to recipient or to its delegate, according 
to which of the two is acting. 


Usage Requirements 


Represent the following classes of authentication: 

a) Basic: Using basic authentication mechanisms such as passwords; or 

b) Enhanced: Using enhanced authentication such two factor authentication mechanisms linked 
to a one time password; or 

c) AdES: Using advanced electronic signatures; or 

d) AdES-Plus: Using advanced electronic signatures issued by means of Secure Signature 
Creation Devices (as defined in Directive 1999/93/EC [1]) or equivalent secure cryptographic 
device; 

e) QES: Using advanced electronic signatures issued by means of Secure Signature Creation 
Devices and supported by Qualified Certificates (as defined in Directive 1999/93/EC [1]). 

NOTE: See also TS 1 02 640-3 [i.3], clause 6.3 on "Sender/Recipient Authentication"). 

The default class of authentication is Basic. 

In case authentication mechanism has value of c), d) e) the sender's PKCS#7 detached (*.p7s) 

shall be present. 

In case authentication mechanism has value a) the sender's UID may be added. 

Extensibility fields may be used to enable the REM-MD to include any 

other relevant details of the authentication used. 



5.2.2.4 Messaging Components 

5.2.2.4.1 MOO - REM-MD Message/REM Dispatch details 



Description 


REM-MD Message/REM Dispatch details, including Message identifier. 


Format 


Structured. 


Meaning 


Message info, containing in particular: 
Message subject 
Message Identifier by UA 
Message Identifier by REM-MD 
Hash Algorithm 
Hash Value 


Usage Requirements 


The hashing algorithm shall also be specified (e.g. "SHA-1", "SHA256") in the REM Practice 
statement or REM Policy (see part 3, clause 6.1). 
Guidance on hashing algorithms is given in TS 102 176-1 [5]. 
Hash value shall be computed according to the following rules: 

1) When the message is a REM Dispatch or a REM-MD message conveying a receipt: the 
hash is computed over the entire Original Message submitted by the sender, attachments 
included, to ensure a tight coupling between the Original Message itself and all other 
information related to all related REM-MD Messages/REM Dispatches. 

2) When the message is a REM-MD Message conveying a notification (S&N mode of 
operation): the hash is computed over the text of the notification message. 



5.2.2.4.2 M01 - Reply-to 



Description 


Message Reply-to header. 


Format 


e-mail address in text. 


Meaning 


Message reply-to header, as in the original message. 


Usage Requirements 
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5.2.2.4.3 M02 - Notification IVIessage Tag 



Description 


Notification Tag. 


Format 


Boolean, 'true' for notification 'false' for not notification. 


IVIeaning 


This tag specifies whether the associated message includes the Original Message, or it is a 
notification message with a reference to the Original Message. 
The default value for this component is "false". 


Usage Requirements 





5.2.2.4.4 M03 - Message Submission Time 



Description 


This field specifies the message submission time. 


Format 


DATE TIME. 


IVIeaning 


Date and time when the sender submitted the original message. 


Usage Requirements 


This field may differ from Event Time in SubmissionAcceptanceRetrieval REM-MD Evidence, 
since message submission does not necessarily coincide with message acceptance/refusal. 



5.2.2.4.5 I\/I04 - Forwarded to external system 



Description 


This component is used when the message is forwarded to a system outside the REM borders. 


Format 


Text. 


IVIeaning 


Provides a description of the external system to which the message has been forwarded 
(non REM e-mail system, ordinary paper mail system, etc.). 


Usage Requirements 





5.2.3 REM-MD Evidence Components formats and values 

REM-MD Evidence Data Elements are elementary pieces of information used to make up the REM-MD Evidence 
Components. 

5.2.3.1 Free text 

Information in free text shall be written in UK English. Text in other languages may be added. 

5.2.3.2 Events 

In accordance with TS 102 640-1 [i.2], clause 6.2. 

Table 1 



Events 



S-REM-MD Acceptance 



S- REM-MD Rejection 



R-REM-MD Acceptance 



R-REM-MD Rejection 



Expiration of time to deliver to R-REM-MD 



REM-MD Message/REM Dispatch Delivery 



Expiration of time to deliver REM-MD Message/REM Dispatch 



Download 



Expiration of time for download 



Download by a recipient's delegate 



Retrieval 



Expiration of time for Retrieval 



Retrieval by a recipient's delegate 



Rejection of download by recipient 



Successful forwarding for Ordinary e-mail 



Unsuccessful forwarding for Ordinary e-mail 



Successful forwarding for Printing 



Unsuccessful forwarding for Printing 



Message received from a regular e-mail system 
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5.2.3.3 Reasons 

Appropriate codes for reasons will be provided in annexes A, B and C. 

5.2.3.3.1 Reasons related to Sender's Submission 

Table 2 



Reason 



Message accepted 



Invalid message format 



Malware found in REM-MD Message/REM Dispatch 



Invalid sender's signature format 



Sender's signing certificate expired or revoked 



Sender's REM-PD or REM-MD policy violation, e.g.: max message size exceeded, invalid attachment formats, etc. 



Other 



5.2.3.3.2 Reasons related to the Relay to the recipient's REM-MD 

Table 3 



Reason 



REM-MD Message/REM Dispatch successfully delivered to, and accepted by, the Recipient's REM-MD 



REM-MD Message/REM Dispatch successfully delivered to, but rejected by, the Recipient's REM-MD for: Invalid 
message format 



REM-MD Message/REM Dispatch successfully delivered to, but rejected by, the Recipient's REM-MD for: Malware found 
in REM-MD Message/REM Dispatch 



REM-MD Message/REM Dispatch successfully delivered to, but rejected by, the Recipient's REM-MD for: Invalid 
message signature format 



REM-MD Message/REM Dispatch successfully delivered to, but rejected by, the Recipient's REM-MD for: Signing 
certificate expired or revoked 



REM-MD Message/REM Dispatch successfully delivered to, but rejected by, the Recipient's REM-MD for: Recipient's 
REM-PD or REM-MD policy violation, e.g.: max message size exceeded, invalid attachment formats, sender's REM-MD 
(or regular e-mail server) non accepted 



REM-MD Message/REM Dispatch non delivered to the Recipient's REM-MD for: Recipient's REM-MD malfunction 



REM-MD Message/REM Dispatch non delivered to the Recipient's REM-MD for: Recipient's REM-MD not identified in 
the Internet 



REM-MD Message/REM Dispatch non delivered to the Recipient's REM-MD for: Recipient's REM-MD unreachable 



REM-MD Message/REM Dispatch non delivered to the Recipient's REM-MD for: Unknown Recipient 



Other 



5.2.3.3.3 Delivery/download related reasons 

Table 4 



Reason 



REM-MD Message/REM Dispatch successfully delivered to /downloaded by | the recipient 



REM-MD Message/REM Dispatch successfully delivered to /downloaded by | a recipient's delegate 



The sender's REM-MD received within a given period no information on delivery from the recipient's REM-MD 



Invalid REM-MD Message/REM Dispatch format 



Malware found in REM-MD Message/REM Dispatch 



Mailbox full 



Technical malfunction 



Attachment formats non accepted 



REM-MD Message/REM Dispatch rejection by the Recipient 



Retention period expired without downloading/successful delivery 
Other 
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5.2.3.3.4 Retrieval reasons 

Table 5 



Reason 



REM-MD Message/REM Dispatch successfully retrieved by the recipient 



REM-MD Message/REM Dispatch successfully retrieved by a recipient's delegate 



Invalid REM-MD Message/REM Dispatch format 



Malware found in REM-MD Message/REM Dispatch 



Technical malfunction 



Attachment formats non accepted 



Retention period expired without retrieval 



Other 



5.2.3.3.5 Reasons related to forwarding REM Message to a non REM external system 

Table 6 



Reason 


Successful 


Regular e-mailing system unreachable 


Regular e-mailing system non operational 


Regular e-mailing system rejected submission (see note) 


Printing system unreachable 


Printing system non operational 


Printing buffer full 


Other 


NOTE: Reason codes provided by the e 


-mailing system can be 


specified. 





REM Signatures 



Clauses above have discussed the structure of the REM-MD Messages/REM Dispatches and the range of REM-MD 
Evidence suitable to uphold certain assertions, which are provided to the users in addition to the services provided by 
ordinary e-mail systems. 

This clause focuses on the usage of electronic signatures within REM-MD Messages/REM Dispatches. 

Clause 6.1 identifies the different types of electronic signatures that may appear within the REM-MD Messages/REM 
Dispatches, and general rules that govern their presence within one REM-MD Message/REM Dispatch. 

Clause 6.2 specifies common requirements on all the types of signatures within a REM-MD Message/REM Dispatch. 

Clause 6.3 specifies requirements on signatures applied to individual REM-MD Evidence objects within a REM-MD 
Message/REM Dispatch. 

Clause 6.4 specifies requirements on signatures placed in the REM-MD Message/REM Dispatch to protect all the parts 
of a REM-MD Message/REM Dispatch including the Original Message and REM-MD Evidence objects added. 

6.1 Electronic signatures within REM-MD Messages/REM 
Dispatches 

Within a REM-MD Message/REM Dispatch the following electronic signatures may appear: 

• Signatures generated by a REM-MD or by the delegated entity on each REM-MD Evidence individually. 

• S/MIME signature protecting all the MIME parts (including not only REM-MD Evidence) that constitute a 
REM-MD Message/REM Dispatch. This signature is generated by a REM-MD. 
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Senders may sign the original message submitted to the recipient, supporting the signature with their certificates - 
quahfied or not quaUfied. These signatures are outside of the scope of the present document. 

If a REM-MD Message/REM Dispatch contains REM-MD Evidence, these have to be signed by the REM-MD in 
charge of generating them. This may be done by individually signing each REM-MD Evidence and make these 
signatures part of the REM-MD Evidence themselves or by generating a S/MIME signature on all the parts of the 
REM-MD Message/REM Dispatch. The present document does not preclude the co-existence of both types of 
signatures, as the first one secures the REM-MD Evidence and the second one also secures other parts of the REM-MD 
Message/REM Dispatch. 

If a REM-MD Message/REM Dispatch contains references to a REM-MD Repository within a REM-MD, then the 
REM-MD generating the REM-MD Message/REM Dispatch will generate an S/MIME signature on all the parts of the 
REM-MD Message/REM Dispatch. REM-MD Evidence may also be individually signed. 

6.2 Common Requirements on Signatures 

The following requirements apply to all type of signatures applied by the REM-MD: 

1) Electronic signatures should be Advanced Electronic Signatures (AdES) as per specifications 
TS 101 903 (XAdES) [4] or TS 101 733 (CAdES) [3] or TS 102 778 [17] (PAdES). 

2) These electronic signatures may include a signed property containing the explicit identifier of the Electronic 
Signature Policy governing the signing and verifying processes. 

It is reconmiended, however, that signature policy requirements, or the signature policy identifier, be included 
in REM Practice Statement (see TS 102 640-3 [i.3], clause 6.1). 

3) These electronic signatures should include a signed property containing the signing time claimed by the 
REM-MD. 

NOTE: All the REM-MD Evidence carry one or more date and time elements. If the REM-MD signature is 

known to be valid the REM-MD Evidence signer's time indications may also be trusted. This time should 
not, however, be used to check signature validity. 

4) These electronic signatures should include a signed property protecting the signing certificate. 

5) Once generated a signature time-stamp may be computed and added to these electronic signatures. 

6.3 Requirements on Signatures Applied to REM-MD Evidence 

The following clauses specify requirements for signature applied to REM-MD Evidence objects for the three data 
formats supported: XML, ASN.l and PDF applying the common requirements in the context of specific data formats. 

6.3.1 XML Signatures 

The following requirements apply to XML Signatures applied to REM-MD Evidence encoded in XML: 

1) The signature should be an XML Advanced Electronic Signature as specified in TS 101 903 (XAdES) [4]. 

2) The signature should be an enveloped signature as specified in clause 10 of W3C Recommendation for XML 
Signature syntax and Processing [7] . 

3) Signature Policy employed may be identified in the property SignaturePolicyldentif ier. 

4) The signing certificate should be protected. It is RECOMMENDED that this be achieved using the XAdES 
attribute xades:SigningCertificate. However, this may be achieved by ds:KeyInfo/X509Data/X509Certificate 
present AND ds:KeyInfo included in the signature. 

5) The signature should include xades : SigningTime . 

6) The signature may include a time-stamp of the signature in xades : SignatureTimeStamp . 
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6.3.2 ASN.1 Signatures 

The following requirements apply to Signatures applied to REM-MD Evidence encoded in ASN. 1 : 

1) The signature should be an Advanced Electronic Signature as specified in TS 101 733 (CAdES) [3]. 

2) The signature should be an "Enveloping with data" signature as specified in clause 5.2 of 
RFC 3852 Cryptographic Message Syntax [2]. 

3) The signature policy employed may be identified in the signature -policy- identifier signed attribute. 

4) The signing certificate should be protected using signed attribute ESS-signing-certificate-v2 as 
defined in TS 101733 [3]. 

5) The signature should include signed attribute signing-time . 

6) The signature may include a time-stamp of the signature in the Unsigned attribute s ignature - 1 ime - 
stamp . 

6.3.3 PDF Signatures 

It is recommended that PDF documents are protected by PAdES signatures. The signature profile specified in 
TS 102 778-2 [18] may be used. It is recommended that systems migrate to use TS 102 778-3 [19] by 2012. 

6.4 Electronic signatures on REM-Message 

Signatures applied to REM-MD Messages/REM Dispatches to protect all parts of the message shall meet the following 
requirements: 

1) The signature shall be placed in the message using S/MIME multipart/signed as defined in RFC 3851 [8]. 



7 Reliable REM-MD Envelopes exchange across 

REM-PD 

REM-MDs belonging to different REM-PDs may need to reliably implement a seamless mutual exchange of REM-MD 
Envelopes (be they actually REM Dispatches or REM-MD Messages). In this case, in addition to the interoperability 
related technicalities, it is indispensible, in order to achieve the desired reliability, that all the interested entities 
(i.e. Relying Parties) have access to the information on the abidance of the involved REM-MDs by the respective REM- 
PD rules. This access is required to be possible independently from what REM-PD the enquiring Relying Parties belong 
to. However, in a more restrictive implementation only a limited number of REM-PDs can agree to share this 
information type, thus not making it publicly open to anyone. 

Apart from the latest case, where the restricted number of entities (i.e. REM-PDs) can agree on a bespoke solution, it is 
advisable that the information exchange mechanism is as open as possible, so that, in subsequent times. Relying Parties 
belonging to additional REM-PDs can access the information at issue. 

The recommended common mechanism is the Trust-service Status List (TSL) specified in the TS 102 231 [6]. 

NOTE: It is worth mentioning that TSL is being adopted in the European Union to share information on which 
Certification Service Providers - CSP - are reported as abiding by the regulation of the respective EU 
Member States - EUMS - on issuing ad managing Qualified Certificates. 

In the following clauses different implementation types are described, where each REM-PD Authority that governs one 
REM-PD assesses the compliance of the REM-MDs, belonging to the REM-PD it governs, with the rules established 
for that REM-PD. 

All the following implementation types do not intend to specify legal liabilities that are left to the applicable provisions. 



ETSI 



36 ETSI TS 1 02 640-2 V2.1 .1 (201 0-01 ) 



7.1 Closed REM-PD 



In one closed REM-PD, i.e. that envisages no interaction with other REM-PDs, any mechanism may be implemented to 
provide REM-PD wide accessibility to the REM-MD status information. 

Where the TSL is used to this purpose it would list the related REM-MD, specifying, as indicated in TS 102 231 [6], 
both their current status and, optionally, their status history. Any entity belonging to the same REM-PD would access 
the TSL and verify its authenticity as provided for by the REM-PD rules. In this TSL, the signing public key of each 
REM-MD, or preferably its corresponding certificates, would be published so that any relying party would be able to 
use it to verify their signature on each REM-MD Envelope they issue. Where applicable, the history of the REM-MDs' 
status (when it was initially approved, when, possibly, such approval was revoked and when was subsequently 
reinstated) could be also found in the TSL, allowing users to ascertain the reliability in the past of a specific REM-MD 
Envelope. The following provisions apply. 

a) The signature should be of the C/XAdES-T type as specified in TS 101 733 [3] and TS 101 903 [4]. No other 
extended signature forms are deemed necessary from the TSL verification standpoint. 

b) The TSL should be reissued at regular intervals to avoid the risk that two valid TSLs exist at the same time. A 
risk would in fact arise if users download one TSL soon after its issue time, then cache it and refer only to the 
cached copy up to the time specified in the "Next update" field (TS 102 231 [6] clause 5.3.15), without 
checking at every verification if a new TSL has been issued in the meantime. Should instead a new TSL be 
issued much ahead of the time specified in the "Next update" field, there would be two, or even more, non 
expired TSLs available, with negative consequences. Such overlap might instead be acceptable if it is just of 
few minutes. 

c) The TSL issue interval should not be longer than few months, depending on the volatility of the governed 
REM-MDs, to match the following requirements: 

1) timely updating the related REM-MDs status information; 

2) ensuring that the TSL signing certificate does not expire between two subsequent TSLs. The Authority's 
key pair and, where applicable, the related certificate should in fact be updated in advance of at least two 
TSL issuing intervals before the certificate expiration date. 

d) The TSL signing public key should be made available to the interested entities through secure and reliable 
means, the choice of which is left up to the REM-PD governing Authority. One reliable means could for 
example be to publish its digest on an Official Journal. 

e) One REM-PD that has no interest to being interoperable with other REM-PDs may adopt other technical 
mechanisms form the TSL, but it should however enforce the above specified organisational provisions 

7.2 Interoperable REM-PDs TSL - No Root TSL 

Version 2 and subsequent ones of TS 102 231 [6] make it possible to point from the TSL issued by one REM-PD 
Authority to the TSLs published by other REM-PD Authorities. Optionally one REM-PD Authority may implement a 
mechanism different from the TSL to point to other REM-PDs TSLs, but the at least the TrST based mechanism to go 
back to the relevant TSL-based information or to any equivalent information shall be implemented to ensure 
interoperability. 

If a REM-PD authority makes use of TSL to point to other TSLs issued by different Authorities, each TSL issuer shall 
implement what is specified in clause 7.1 where, to ensure interoperability, in provisions a), b), d), the "should" 
keyword is to be changed in "shall". 

Additionally what is hereinafter specified also applies. 

In the case addressed by this clause, each REM-PD Authority, depending on the REM-PD rules, has the right to 
recognise a number of other REM-PDs and to specify their recognition status in the TSL it issues and maintains. 

Each TSL issuer shall collect in a reliable way the information, to be placed in its TSL, about the "external TSLs" 
whereabouts (i.e. URL) and digital identity (e.g. the signer's certificate) through which the related TSLs can be accessed 
and its integrity and authenticity can be verified. 
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One TSL issuer may act in onde of the following two ways: 

1) it may list the recognised external REM-PDs along with the "List of Trust Service Providers" detailed in 
clause 5.3.17 of the TS 102 231 [6]; 

2) it may implement a tuple of what can be called a "Base TSL", of type "Generic", and a "Bridge TSL", of Type 
"Schemes", (as defined in clause "5.3.3 TSL type" of TS 102 231 [6]); 

3) the "Base TSL" would only lists REM-MDs belonging to the REM-PD at issue and would point, by means of 
the field "Pointers to other TSLs" (TS 102 231 [6] clause 5.3.13), to the "Bridge TSL" that would Hst only 
external REM-PDs in its "List of Trust Service Providers" section. 

It is to be remarked that the pointed-to REM-PDs may or may not reciprocate the recognition. 

7.2.1 Interoperable REM-PDs TSL - No Root TSL: an example 

Figure 3 presents a possible usage of TSL for interoperable REM-PDs with no Root TSL. Different types of TSLs are 
represented, with their relationships, in detail: 

1) REM-PD 1 implements one "Base TSL - Bridge TSL" mechanism; its Base TSL points to the Bridge TSL that 
in turn points to the TSLs of the other domains recognised by the governing Authority; 

2) REM-PD 2 implements a TSL of Type "Generic" where REM-MDs internal to the REM-PD are Hsted along 
with the external REM-PDs recognised by the REM-PD 2 Authority; it can be noticed that in this example 
REM-PD 2 does not recognise REM-PD 1, while it recognises REM-PDs 3 and 4; 

3) REM-PD 3 implements a "Generic" TSL; it recognises REM-PDs 1 and 4, but not REM-PD 2; 

4) REM-PD 4 implements one "Base TSL - Bridge TSL" mechanism; its Bridge TSL points to the TSLs of 
REM-PDs 1 and 3, but not to that of REM-PD 2. 




Figure 3 
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7.3 Interoperable REM-PDs TSL - Root TSL 

What is specified in the previous clause 7.1 apply. To ensure interoperability in provisions a), b), d), the "should" 
keyword is to be changed in "shall". 

Additionally what is hereinafter specified also applies. 

In this TSL implementation a Higher Authority assesses the abidance by the common rules only of the directly 
governed REM-PDs that will in turn be responsible to assess the abidance by the respective REM-PD rules of each 
REM-MD they govern. 

This higher Authority is responsible to issues and maintain a Root TSL, of Type "Schemes", where the "lower level" 
REM-PDs, that in turn issue their own TSLs, are listed as TSPs. In the Root TSL each TSL entry related to one of these 
"lower level" REM-PD points to the TSL issued by the relevant governing Authority as well as the digital identity 
(e.g. the signer's certificate) with which the related TSLs integrity and authenticity can be verified. Likewise, all subject 
TSLs point to the Root TSL. 

In this case this Higher Authority shall be responsible to collect in a reliable way the above mentioned information on 
the ""lower level TSLs" URL and digital identity. 

7.3.1 Interoperable REM-PDs TSL - Root TSL: an example 

Figure 4 presents a possible usage of TSL for interoperable REM-PDs with Root TSL. 
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Annex A (normative): 

REM-MD Evidence Implementation in ASN.1 

This annex defines the syntax for REM-MD Evidence when ASN. 1 is used. 

This clause specifies the ASN.l structures to be used when implementing an ASN. 1 -version of the evidence. 

The ASN.l syntax used in this annex is the 1988 version, as defined by ITU-T Recommendations X. 680-683 [10] with 
the addition of "UTF8String" type imported from the hybrid ASN.l module of RFC 5280 [14]. These additions are 
imported so as to enhance interoperability by avoiding ambiguity concerning signature algorithms and digest 
calculation. The following schema requires the use of a "relaxed compiler" to accommodate these two special types. 

The ASN.l in this annex may be converted into the 1997 syntax by using the Information Object Classes introduced by 
that version to replace the type "ANY DEFINED BY" (this type not being supported by the 1997 version) and removing 
the importation of "UTF8String" type, plus amending the module header appropriately. 

The ASN. 1 implementation of the evidence shall be encoded by using the Distinguished Encoding Rules defined by 
ITU-T Recommendation X.690 [11]. 

The header of the ASN.l module is specified as follows. 

ETSI-REM-vl-88syntax { itu-t(O) identif ied-organization (4) etsi(O) 

tsl-specif ication (1234) id-mod(O) vl-88syntax (1) } 
DEFINITIONS EXPLICIT TAGS ::= 

BEGIN 

-- EXPORTS All 
IMPORTS 

-- Internet X.509 Public Key Infrastructure - Certificate and CRL Profile: RFC 5280 
Extensions 

FROM PKIXlExplicit88 { iso(l) identif ied-organization (3 ) dod(6) internet (1) 
security (5) mechanisms (5) pkix(7) id-mod(O) id-pkixl-explicit (18) } 
-- Cryptographic Message Syntax (CMS) : RFC 3852 
Contentlnfo 

FROM CryptographicMessageSyntax2 04 { iso(l) member -body (2) us (840) rsadsi (113549) 
pkcs(l) pkcs-9(9) smime(16) modules (0) cms-2004(24) } 
-- Provision of harmonized Trust-service status information (TSL) - ETSI TS 102 231 V2 . 1 . 1 
NonEmptyURI, Mult iLangSt ring, MultiLangAddress, Elect ronicAddresses, LanguageTag, Count ryCode 
FROM ETSI-TSL-v2-88syntax { itu-t(O) identif ied-organization (4 ) etsi(O) 
tsl-specif ication (2231) id-mod(O) v2-88syntax (1) } 
-- AFNOR - AuthorizedCertif icate 
AuthorizedCertif icate 

FROM EEvidenceCommon { iso(l) member -body (2) fr(250) type-org(l) 

aFN0RStandardisation(127) letter (26) standard (74600) asnl-modules (3) common (0) } 



Clause A.l defines the general structure for REM-MD Evidence and provides details for their elements. 
Clause A.2 specifies the different types of REM-MD Evidence as defined in clause 5.1. 



A.1 REM-MD Evidence Structure 

Clause 5.2.1 shows a template for REM-MD Evidence. The present clause defines the ASN.l syntax for REM-MD 
Evidence. 

Below follows the root for all the OIDs defined in the present document. 

id-rem OBJECT IDENTIFIER ::= { ETSl-REM-vl-88syntax } 
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Below follows the asnl definition for REM-MD Evidence. 



REMEvidence : : = SEQUENCE { 




version 


Version, 


eventCode 


INTEGER OPTIONAL, 


eventReasons 


EventReasons OPTIONAL, 


evidenceldentif ier 


UTFSString (SIZE (1..MAX)), 


evidencelssuerPolicylD 


[1] Policyldentifiers OPTIONAL, 


evidencelssuerDetails 


EntityDetails, 


senderAuthenti cat ionDe tails 


[2] AuthenticationDetails OPTIONAL, 


rec ipientAuthenti cat ionDe tails 


[3] AuthenticationDetails OPTIONAL, 


eventTime 


GeneralizedTime, 


submi s s i onTime 


General izedTime OPTIONAL, 


replyTo 


UTFSString OPTIONAL, 


senderDetails 


EntityDetails, 


recipient sDetails 


EntityDetailsList, 


recipient sDelegatesDetails 


[4] RecipientsDelegatesDetails OPTIONAL, 


evidenceRefersToRecipient 


[5] INTEGER OPTIONAL, 


senderMessageDe tails 


[6] MessageDetails OPTIONAL, 


not ificationDet ails 


[7] MessageDetails OPTIONAL, 


forwardedToExternal System 


[8] UTFSString OPTIONAL, 


transact ionLoglnformat ion 


[9] TransactionLoglnformation OPTIONAL, 


extensions 

} 


[10] Extensions OPTIONAL 



Field version for the present document is as follows: 



Version ::= INTEGER { vl(l) 



Clauses below further develop the elements of a REM-MD Evidence. 

A.1 .1 Field eventCode 

This field has the semantics of G02 data element as specified in clause 5.2.2.1.3. Its content is an integer. 
The present document has identified a number of events, whose identifiers are defined below. 

1) Acceptance of some REM-MD Message/REM Dispatch by some entity. 

2) Re j ect ion of some REM-MD Message/REM Dispatch by some entity. 

3) Del i very of some REM-MD Message/REM Dispatch to some entity. 

4) Non del i very of some REM-MD Message/REM Dispatch to some entity within a certain period of time. 

5) Download of some REM-MD Message/REM Dispatch by recipient or recipient's delegate from a REM's 
REM-MD Repository. 

6) No download of some REM-MD Message/REM Dispatch by recipient or recipient's delegate from a REM's 
REM-MD Repository within a certain period of time. 

7) Retrieval of some REM-MD Message/REM Dispatch by recipient from recipient's mailbox. 

8) Non retrieval of some REM-MD Message/REM Dispatch by recipient from recipient's mailbox within a 
certain period of time. 

9) Re j e c t i on of download of a message by recipient. 

10) Forward of REM-MD Message/REM Dispatch to a regular e-mail system. 

11) Forward of REM-MD Message/REM Dispatch to a printing system to be subsequently sent via physical 
registered mail. 

12) Reception of a message from a regular e-mail system. 
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A.1 .2 Field eventReasons 



This field has the semantics of G03 data element as specified in clause 5.2.2.1.4. 
It is an instance EventReasons type, which is defined below. 



EventReasons ::= SEQUENCE SIZE (1..MAX) OF EventReason 

EventReason : : = SEQUENCE { 
code INTEGER, 
details UTFSString OPTIONAL 



Field eventReasons contains a list of eventReason elements. 

eventReason's field code contains the reason code as an integer. Annex D of the present document shows the codes 
for event reasons already identified by the present document. 

eventReason's optional field details contain a string with additional details. 

A.1.3 Field evidencelssuerPolicylD 

This field has the semantics of ROl data element as specified in clause 5.2.2.2.1. It is an instance 
Policyldentif iers type, which is defined below. 

Policyldentifiers ::= SEQUENCE SIZE (1..MAX) OF Policyldentif ier 

Policyldentif ier ::= CHOICE { 
oid OBJECT IDENTIFIER, 
uri NonEmptyURI 



The content of this field will be a sequence of policies identifiers. Each policy identifier is a choice between an OID and 
an URI, as both mechanisms may be used for identifying a policy. 

Field oid, if present, shall contain an OID and field uri, if present shall contain an URI. 

A.1 .4 Field evidenceldentifier 

This field has the semantics of GOO data element as specified in clause 5.2.2.1.1. It contains a unique identifier of the 
REM-MD Evidence for the REM-MD Evidence Issuer. 

All the REM-MD Evidence generated by a certain REM-MD Evidence Issuer shall have different identifiers. The 
present document does not specify any further restriction on the values of this element. 

A.1 .5 Field evidencelssuerDetails 

This field has the semantics of R02 data element as specified in clause 5.2.2.2.2. It is an instance of EntityDetails 
type, which is defined below. 

EntityDetails ::= SEQUENCE { 

namesPostalAddresses [1] NamesPostalAddresses OPTIONAL, 

electronicAddress [2] ElectronicAddresses OPTIONAL, 

certif icateDetails [3] AuthorizedCertif icate OPTIONAL 

} 

NamesPostalAddresses ::= SEQUENCE SIZE (1..MAX) OF NamePostalAddress 

NamePostalAddress ::= SEQUENCE { 

entityName [1] EntityName OPTIONAL, 
postalAddress [2] PostalAddress OPTIONAL 
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EntityName ::= SEQUENCE { 

languageTag [1] LanguageTag OPTIONAL, 

namelnstance [2] UTFSString (SIZE (1..MAX)) 
} 

PostalAddress ::= SEQUENCE { 

languageTag LanguageTag, 

streetAddress MultiLineStreetAddress , 

locality UTFSString (SIZE (1..MAX)), 

stateOrProvince [1] UTFSString (SIZE (1..MAX)) OPTIONAL, 

postalCode UTFSString (SIZE (1..MAX)), 

countryName CountryCode 
} 

MultiLineStreetAddress ::= SEQUENCE SIZE (1..MAX) OF UTFSString (SIZE (1..MAX)) 



When present, optional namesPostalAddresses field contains a list of name PostalAddress fields. Each 
namePostalAddresss may contain the entity's name (entityName field) and/or the postal address 
( PostalAddress field) in a specific language, which is indicated by the corresponding languageTag fields 
within the types. Field entityName allows for more than one string for the name. Field postalAddress allows for 
more than one string for indicating details of the street. 

When present, optional ElectronicAddress field contains the entity's electronic address (for instance an e-mail 
address, although not necessarily). 

Field certif icateDetails is an instance of AuthorizedCertif icate type that contains details of the user's 
certificate. See [15] for details. 

A.1 .6 Field senderAuthenticationDetails 

This field has the semantics of 104 data element as specified in clause 5.2.2.3.5. It is an instance 
Authent i cat ionDe tails type, which is defined below. 

AuthenticationDetails ::= SEQUENCE { 

authent icationTime GeneralizedTime, 

authent icationMethod INTEGER, 

additionalDetails AdditionalDetails OPTIONAL 

} 

AdditionalDetails ::= SEQUENCE SIZE (1..MAX) OF Contentlnfo 

Field authent icationTime indicates the time when the sender was authenticated. 

Field authent icationMethod contains info on the method used for authenticating the sender. The following 
methods and codes have already been identified: 

" 1 " . Basic: Using basic mechanisms such as passwords. 

" 2 " . Enhanced: Using enhanced authentication such two factor mechanisms linked to a one time password. 

" 3 " . Strong: Using Strong authentication using client certificate via mutual SSL. 

" 4 " . AdES: Using advanced electronic signatures. 

" 5 " . AdES-Plus: Using advanced electronic signatures with Secure Signature Creation Devices (as defined in 
Directive 1999/93/EC [1]) or equivalent secure cryptographic device. 

" 6 " . QES: Using advanced electronic signatures with Secure Signature Creation Devices and Qualified 
Certificates (as defined in Directive 1999/93/EC [1]). 

Optional field additionalDetails contains additional details on the authentication process. It may contain, for 
instance, the token presented by the sender to the sender's REM-MD. If signature has been used for authentication, one 
of the elements of the sequence may be the sender's signature itself. 
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A.1.7 Field recipientAuthenticationDetails 

This field has the semantics of 105 data element as specified in clause 5.2.2.3.6. It is an instance of type 

Authent i cat ionDe tails. 



A.1 .8 Field eventTime 

This field has the semantics of G05 data element as specified in clause 5.2.2.1.6. It is an instance of 

General izedTime. 



A.1.9 Field submissionTime 

This field has the semantics of M03 data element as specified in clause 5.2.2.4.4. It is an instance of 

General izedTime. 

A.1.10 Field replyTo 

This field has the semantics of MOl data element as specified in clause 5.2.2.4.2. 

A.1 .1 1 Field senderDetails 

This field has the semantics of 100 data element as specified in clause 5.2.2.3.1. It is an instance of EntityDetails 
type, which has been defined in clause A. 1.5. 



A. 1.1 2 Field recipientsDetails 



This field has the semantics of 101 data element as specified in clause 5.2.2.3.2. It is an instance of 
EntityDetailsList type, which is defined below. 

EntityDetailsList ::= SEQUENCE SIZE (1..MAX) OF EntityDetails 

Each entityDe tails field contains the details of one of the recipients of the message. 

A. 1.1 3 Field recipientsDelegatesDetails 

This element has the semantics of 102 data element as specified in clause 5.2.2.3.3. It is an instance of UserDe tails 
type, which is defined below. 

RecipientsDelegatesDetails ::= SEQUENCE SIZE (1..MAX) OF RecipientsDelegateDetails 

RecipientsDelegateDetails ::= SEQUENCE { 

delegateDetails EntityDetails, 

delegatingRecipients List Of Integers 
} 

ListOflntegers ::= SEQUENCE SIZE (1..MAX) OF INTEGER 

Field delegateDetails contains the details of the delegate in question. 

Field delegatingRecipients contains a list of integers that identify the recipients that have delegated in this 
entity. First Recipient in recipientsDetails is assigned number 1. If this element is absent, then the delegate 
will act as delegated of all the recipients. 
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A. 1 . 1 4 Field evidenceRefersToRecipient 

This field has the semantics of 103 data element as specified in clause 5.2.2.3.4. Its value references one of the 
recipients in recipientsDe tails field. First recipient in the list of recipients is assigned number 1. 

A. 1 . 1 5 Fields senderMessageDetails and 
notificationMessageDetails 

Fields senderMessageDetails and notificationMessageDetails are instances of Me ssageDe tails 
type, which is defined below. 



MessageDetails ::= SEQUENCE { 




isNotif ication 


BOOLEAN OPTIONAL, 


messageSub j ect 


UTFSString, 


uaMessageldentif ier 


[1] UTFSString OPTIONAL, 


messageldentif ierByREMMD 


[2] UTFSString, 


hashAlgorithm 


OBJECT IDENTIFIER OPTIONAL, 


hash 
} 


BIT STRING OPTIONAL 



Field i sNot i f i cat ion indicates whether the message whose details are provided is a notification (a message 
containing a pointer to the sender's message) or not. Absence of this field means that the message is not a notification. 

If present, optional messageSubj ect field contains the value of the Subject field of the message. 

If present, optional uaMessageldentif ier field contains an identifier as computed by the user's UA. 

Mandatory messageldentif ierByREMMD field contains an identifier computed by a REM-MD. This identifier 
shall be unique for this REM-MD. 

Finally, optional fields hashAlgorithm and hash, if present contain the message's digest algorithm identifier and 
the digest value computed on the sender's message respectively. 

A. 1.15.1 Field senderMessageDetails 

Field senderMessageDetails has the semantics of MOO data element as specified in clause 5.2.2.4.1 when it 
contains details of the sender's message. As it has been said before this field is an instance of MessageDetails type. 

Evidence not reporting events on notifications shall contain the senderMessageDetails field. 

When this field is present in an evidence, the following requirements apply to their children fields: 

Field isNot if ication may be present (in which case its value shall be " false ") or not (as absence of 
this attribute means that the details do not correspond to a notification). 

Field messageSubj ect shall be present. 

Field uaMessageldentif ier may be present. 

Field me s s age I den t i f i e rByREMMD shall be present. 

Fields hashAlgorithm and hash shall be present. 

A. 1.15. 2 Field notificationMessageDetails 

Field notificationMessageDetails has the semantics of MOO data element as specified in clause 5.2.2.4.1 
when it contains the details of a notification (a message containing a pointer to the sender's message). This field is an 
instance of MessageDetails type. 
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Evidence reporting events on notifications shall contain the notificationDe tails field. In addition, if evidence 
issuers have access to the sender's message details, then these evidence should also contain the 
senderMessageDetails field. 

When this field is present in an evidence, the following requirements apply to their children fields: 

• Field isNotif ication shall be present and its value shall be " true " . 

• Field messageSubject shall be absent. 

• Field uaMes sage Identifier shall be absent. 

• Field me s s age I den t i f i e rByREMMD shall be present. 

• Fields hashAlgorithm and hash shall be present. 

A. 1 . 1 6 Field forwardedToExternalSystem 

This field the semantics of M04 data element as specified in clause 5.2.2.4.5. 



A.1 .1 7 Field transactionLoglnformation 



This field has the semantics of G06 data element as specified in clause 5.2.2.2.3. It provides a placeholder that issuers of 
evidence may use for including pieces of the log file content within them. 

It is an instance of TransactionLoglnformation type, which is defined below. 

TransactionLoglnformation ::= SEQUENCE SIZE (1..MAX) OF UTFSString 

Field transactionLoglnformation contains a sequence of trans actionLog elements, each one containing 
an instance of log information. 

A. 1.1 8 Field extensions 

This element has the semantics of Enn data element. This element is a placeholder for further standardized or private 
extensions. 

Each extension in an evidence is designated as either critical or non-critical by the critical boolean field. If this 
attribute is present, then the extension is designated as critical. An extension using system shall reject the evidence if it 
encounters a critical extension it does not recognize. A non-critical extension may be ignored if it is not recognized. 



A.2 REM-MD Evidence 

All the evidence specified in clause 5.1 of the present document will be instances of EncapsulatedContent Inf o 
type as defined in RFC 3852 [2]. 

The eContentType field identifies the type of evidence as shown below. 
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id-rem-evidenceTypes OBJECT IDENTIFIER ::= { id-rem 1 } 

id-rem-evidenceTypes-sumbmissionAcceptanceRejection OBJECT IDENTIFIER ::= { id-rem-evidenceTypes 1 } 
-- OID for SubmissionAcceptanceRejection evidence as specified in 5.1.1 

id-rem-evidenceTypes-relayREMMDAcceptanceRejection OBJECT IDENTIFIER ::= { id-rem-evidenceTypes 2 } 
-- OID for RelayREMMDAcceptanceRejection evidence as specified in 5.1.2 

id-rem-evidenceTypes-relayREMMDFailure OBJECT IDENTIFIER ::= { id-rem-evidenceTypes 3 } -- OID for 
RelayREMMDFailure evidence as specified in 5.1.3 

id-rem-evidenceTypes-deliveryNonDeliveryToRecipient OBJECT IDENTIFIER ::= { id-rem-evidenceTypes 4 } 
-- OID for DeliveryNonDeliveryToRecipient evidence as specified in 5.1.4 

id-rem-evidenceTypes-downloadNonDownloadByRecipient OBJECT IDENTIFIER ::= { id-rem-evidenceTypes 5 } 
-- OID for DownloadNonDownloadByRecipient evidence as specified in 5.1.5 

id-rem-evidenceTypes-retrievalNonRetrievalByRecipient OBJECT IDENTIFIER ::= { id-rem-evidenceTypes 6 
} -- OID for RetrievalNonRetrievalByRecipient evidence as specified in 5.1.6 

id-rem-evidenceTypes-acceptanceRejectionByRecipient OBJECT IDENTIFIER ::= { id-rem-evidenceTypes 7 } 
-- OID for AcceptanceRejectionByRecipient evidence as specified in 5.1.7 

id-rem-evidenceTypes-relayToNonREMSystem OBJECT IDENTIFIER ::= { id-rem-evidenceTypes 8 } -- OID for 
RelayToNonREMSystem evidence as specified in 5.1.8 

id-rem-evidenceTypes-receivedFromNonREMSystem OBJECT IDENTIFIER ::= { id-rem-evidenceTypes 9 } -- 
OID for ReceivedFromNonREMSystem evidence as specified in 5.1.9 

The eContent field will be an encapsulated instance of REMEvidence type defined in clause B.l. Clauses below 
specify the contents of each type of evidence by defining further constraints for the different fields of REMEvidence. 

Constraints are expressed in tables organized as follows: 

• Column Field identifies the profiled field. Should an evidence could carry more than one instance of the same 
element, then the usual array syntax of an integer index within square brackets is used for enumerating the 
different instances. Array index numbering starts at 1. 

• Column Mandatory/Optional specifies requirements on the field. The following codes may appear: 

M: This means that the field is mandatory. 

O: This means that presence or absence of the field is optional. 

C: This means that the presence of the field depends on certain conditions that are further developed 
in column Additional Profile Properties. 

• Column Nbr. Occurrences identifies the number of occurrences of the element. 

• Column Additional Profile Properties specifies additional requirements on the field: values, conditions, etc. 
Terms shall, may and should used in these cells have the meaning as specified in TS 102 904 [16]. 
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A.2. 1 Evidence submissionAcceptanceRejection 



The table below shows the contents of this element. 



Field 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


Version 


M 


1 


Value: "i" for this version 


eventCode 


M 


1 


Value if acceptance: "Acceptance" 
Value if rejection: "Rejection" 


eventReasons 


C 


0..1 


If value of eventCode is "Acceptance" 
then this element shall not appear. 
If value of eventCode is "Rej ection" 
then one single instance of this element 
shall appear. The values of their 
eventReason children shall contain the 
codes identifying the reason(s) why the 
REM-MD rejected the message submitted 
by the sender. 


evidence Issuer Pol icy ID 





0..1 




evidence Identifier 


M 


1 


Value as computed by the Evidence issuer. 


evidence I ssuerDetai Is 


M 


1 




senderAuthenticationDetails 


C 


0..1 


If the sender has been authenticated by the 

REM-MD, then this element shall be 

present. Its contents will indicate the 

authentication process details. 

If the sender has not been authenticated by 

the REM-MD, then this element shall not be 

present. 


eventTime 


M 


1 




submissionTime 


M 


1 




replyTo 





0..1 




senderDetails 


M 


1 




recipientsDetails 


M 


1 




recipientsDelegatesDetails 


C 


0..1 


If the evidence is generated for delegated 
entities only, then this element shall appear. 
If the evidence is generated for recipients 
only, then this element shall appear. 


senderMessageDetails 


M 


1 


This field shall be present. 

The requirements for its children fields are 

specified in clause A. 1.1 5.1. 


transact ionLoglnformat ion 





0..1 




Extensions 





0..1 





A.2.2 Evidence RelayREMMDAcceptanceRejection 

The table below shows the contents of this element. 



Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


Version 


M 


1 


Value: "i" for this version 


eventCode 


M 


1 


Value if acceptance by recipient's 

REM-MD: "Acceptance" 

Value if rejection by recipient's REM-MD: 

"Rejection" 


eventReasons 


C 


0..1 


If value of eventCode is "Acceptance" 
then this element shall not appear. 
If value of eventCode is "Rejection" 
then one single instance of this element 
shall appear. The values of their 
eventReason children shall contain the 
codes identifying the reason(s) why the 
REM-MD rejected the message submitted 
by the sender. 
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Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


evidence Identifier 


M 


1 


Value as computed by the Evidence issuer. 


evidence Issuer Pol icy ID 





0..1 




evidencelssuerDetails 


M 


1 




eventTime 


M 


1 


If recipient's REIVI-IVID has accepted the 
message this element shall indicate when 
the acceptance occurred. 
If recipient's REM-MD has rejected the 
message this element shall indicate when 
the rejection occurred. 


replyTo 





0..1 




senderDetails 


M 


1 




recipientsDetails 


M 


1 




recipientsDelegatesDetails 


C 


0..1 


If the evidence is generated for delegated 

entities only, then this element shall 

appear. 

If the evidence is generated for recipients 

only, then this element shall appear. 


evidenceRef ersToRecipient 


C 


0..1 


If the evidence only refers to some 

recipient/delegate then this element shall 

appear. 

If the evidence refers to all the 

recipients/delegates then this element shall 

not appear. 


senderMessageDetails 


C 


0..1 


If the evidence is not an evidence on a 
notification, this field shall be present. 
If the evidence is an evidence on a 
notification and the issuer of the evidence 
has access to the details of the sender's 
message this field should be present. If the 
issuer does not have access to the details 
of sender's message this field shall be 
absent. 

If present, the requirements for its children 
fields are specified in clause A.1. 15.1. 


notif icationMessageDetails 


C 


0..1 


If the evidence is an evidence on a 
notification, this field shall be present. 
If the evidence is not an evidence on a 
notification this field shall be absent. 
If present, the requirements for its children 
fields are specified in clause A. 1 . 1 5.2. 


transact ionLoglnformat ion 





0..1 




Extensions 





0..1 





A.2.3 Evidence RelayREMMDFailure 

The table below shows the contents of this element. 



ETSI 



49 



ETSI TS 102 640-2 V2.1.1 (2010-01) 



Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


Attribute version 


M 


1 


Value: "i" for this version 


eventCode 


M 


1 


For this evidence the value of this code is 
always: "DeliveryExpiration" 


eventReasons 


M 


1 


The values of their eventReason children 
shall contain the codes identifying the 
reason(s) why the sender's REM-MD could 
not deliver the message to recipient's 
REM-MD. 


evidence Identifier 


M 


1 


Value as computed by the Evidence issuer. 


evidence Issuer Pol icy ID 





0..1 




evidence I ssuerDetai Is 


M 


1 




eventTime 


M 


1 


This element will contain the message 
delivery expiration time. 


replyTo 





0..1 




senderDetails 


M 


1 




recipientsDetails 


M 


1 




recipientsDelegatesDetails 


C 


0..1 


If the evidence is generated for delegated 
entities only, then this element shall appear. 
If the evidence is generated for recipients 
only, then this element shall appear. 


evidenceRef ersToRecipient 


C 


0..1 


If the evidence only refers to some 

recipient/delegate then this element shall 

appear. 

If the evidence refers to all the 

recipients/delegates then this element shall 

be absent. 


senderMessageDetails 


C 


0..1 


If the evidence is not an evidence on a 
notification, this field shall be present. 
If the evidence is an evidence on a 
notification and the issuer of the evidence 
has access to the details of the sender's 
message this field should be present. 
If present, the requirements for its children 
fields are specified in clause A.1. 15.1. 


notif icationMessageDetails 


C 


0..1 


If the evidence is an evidence on a 
notification, this field shall be present. 
If the evidence is not an evidence on a 
notification this field shall be absent. 
If present, the requirements for its children 
fields are specified in clause A. 1 . 1 5.2. 


transact ionLoglnformat ion 





0..1 




Extensions 





0..1 





A.2.4 Evidence DeliveryNonDeliveryToRecipient 



The table below shows the contents of this element. 



Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


Attribute version 


M 


1 


Value: "i" for this version 


eventCode 


M 


1 


Value if message ( which may be a 
notification) has been delivered to recipient 
or recipient's delegates: "Delivery" 
Value if message (which may be a 
notification) has not been delivered to 
recipient or recipient's delegates: 
"DeliveryExpiration" . 
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Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


eventReasons 


C 


0..1 


If value of eventCode is "Delivery" 
then this element shall not appear. 
If value of eventCode is 
"DeliveryExpiration" then one 
single instance of this element shall 
appear. The values of their eventReason 
children shall contain the codes identifying 
the reason(s) why the message could not 
be delivered to the recipient or the 
recipient's delegates. 


evidence Identifier 


M 


1 


Value as computed by the Evidence issuer. 


evidence Issuer Pol icy ID 





0..1 




evidence I ssuerDetai Is 


M 


1 




recipientAuthenticationDetails 


C 


0..1 


If the recipient has been authenticated by 

the REM-MD, then this element shall be 

present. Its contents will indicate the 

authentication process details. 

If the recipient has not been authenticated 

by the REM-MD, then this element shall be 

absent. 


eventTime 


M 


1 


If message ( which may be a notification) 
has been delivered to recipient or 
recipient's delegates then this element will 
contain the delivery time. 
If message (which may be a notification) 
has not been delivered to recipient or 
recipient's delegates before the arrival of 
the delivery expiration time, then this 
element will contain the delivery expiration 
time. 


replyTo 





0..1 




senderDetails 


M 


1 




recipient sDetai Is 


M 


1 




recipientsDelegatesDetails 


C 


0..1 


If the evidence is generated for delegated 

entities only, then this element shall 

appear. 

If the evidence is generated for recipients 

only, then this element shall appear. 


evidenceRef ersToRecipient 


C 


0..1 


If the evidence only refers to some 

recipient/delegate then this element shall 

appear. 

If the evidence refers to all the 

recipients/delegates then this element shall 

not appear. 


senderMessageDetails 


C 


0..1 


If the evidence is not an evidence on a 
notification, this field shall be present. 
If the evidence is an evidence on a 
notification and the issuer of the evidence 
has access to the details of the sender's 
message this field should be present. If the 
issuer does not have access to the details 
of sender's message this field shall be 
absent. 

If present, the requirements for its children 
fields are specified in clause A.1. 15.1. 


not ificationMessageDet ails 


C 


0..1 


If the evidence is an evidence on a 
notification, this field shall be present. 
If the evidence is not an evidence on a 
notification this field shall be absent. 
If present, the requirements for its children 
fields are specified in clause A.I. 15. 2. 


transact ionLoglnformat ion 





0..1 




Extensions 





0..1 





ETSI 



51 



ETSI TS 102 640-2 V2.1.1 (2010-01) 



A.2.5 Evidence DownLoadNonDownloadByRecipient 

The table below shows the contents of this element. 



Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


Attribute version 


M 


1 


Value: "i" for this version 


eventCode 


M 


1 


Value if message has been downloaded by 
the recipient (or recipient's delegates) from a 
REM-MD's REM-MD Repository: 
"Download" . 

Value if message has not been downloaded 
by the recipient or recipient's delegates 
before a certain giving time: 
"DownloadExpiration" . 


eventReasons 


C 


0..1 


If value of eventCode is "Download" then 
this element shall not appear. 
If value of eventCode is 
"DownloadExpiration" then one single 
instance of this element shall appear. The 
values of their eventReason children shall 
contain the codes identifying the reason(s) 
why the message could not be downloaded 
by the recipient or the recipient's delegates. 


evidence Identifier 


M 


1 


Value as computed by the Evidence issuer. 


evidence Issuer Pol icy ID 





0..1 




evidencelssuerDetails 


M 


1 




recipientAuthentionDetails 


C 


0..1 


If the recipient (or recipient's delegates) has 
been authenticated by the REM-MD, then 
this element shall be present. Its contents 
will indicate the authentication process 
details. 

If the recipient has not been authenticated by 
the REM-MD, then this element shall not be 
present. 


eventTime 


M 


1 


If message (which may be a notification) has 
been downloaded by the recipient or 
recipient's delegates then this element will 
contain the download time. 
If message (which may be a notification) has 
not been downloaded by the recipient or 
recipient's delegates before the arrival of the 
download expiration time, then this element 
will contain the download expiration time. 


replyTo 





0..1 




senderDetails 


M 


1 




recipientsDetails 


M 


1 




recipientsDelegatesDetails 


C 


0..1 


If the evidence is generated for delegated 
entities only, then this element shall appear. 
If the evidence is generated for recipients 
only, then this element shall appear. 


evidenceRef ersToRecipient 


C 


0..1 


If the evidence only refers to some 

recipient/delegate then this element shall 

appear. 

If the evidence refers to all the 

recipients/delegates then this element shall 

not appear. 


senderMessageDetails 


M 


1 


This field shall be present. 

The requirements for its children fields are 

specified in clause A. 1.1 5.1. 


transact ionLoglnformat ion 





0..1 




Extensions 





0..1 
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A.2.6 Evidence RetrievalNonRetrievalByRecipient 

The table below shows the contents of this element. 



Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


Attribute version 


M 


1 


Value: "i" for this version 


eventCode 


M 


1 


Value if message has been retrieved from 
mailbox: "Retrieval" 
Value if message has not been retrieved 
from mailbox before a giving time: 

"RetrievalExpiration" . 


eventReasons 


C 


0..1 


If value of eventCode is "Retrieval" then 
this element shall not appear. 
If value of eventCode is 
"RetrievalExpiration" then one single 
instance of this element shall appear. The 
values of their eventReason children shall 
contain the codes identifying the reason(s) 
why the message could not be retrieved from 
the mailbox. 


evidence Identifier 


M 


1 


Value as computed by the Evidence issuer. 


evidence Issuer Pol icy ID 





0..1 




evidence I ssuerDetai Is 


M 


1 




recipientAuthenticationDetails 


C 


0..1 


If the recipient (or recipient's delegates) has 
been authenticated by the REM-MD, then 
this element shall be present. Its contents 
will indicate the authentication process 
details. 

If the recipient has not been authenticated by 
the REM-MD, then this element shall not be 
present. 


eventTime 


M 


1 


If message (which may be a notification) has 
been retrieved by the recipient or recipient's 
delegates from mailbox then this element 
shall contain the retrieval time. 
If message (which may be a notification) has 
not been retrieved by the recipient or 
recipient's delegates from mailbox then this 
element shall contain the retrieval expiration 
time. 


replyTo 





0..1 




senderDetails 


M 


1 




recipientsDetails 


M 


1 




recipientsDelegatesDetails 


C 


0..1 


If the evidence is generated for delegated 
entities only, then this element shall appear. 
If the evidence is generated for recipients 
only, then this element shall appear. 


evidenceRef ersToRecipient 


C 


0..1 


If the evidence only refers to some 

recipient/delegate then this element shall 

appear. 

If the evidence refers to all the 

recipients/delegates then this element shall 

not appear. 


senderMessageDetails 


C 


0..1 


If the evidence is not an evidence on a 
notification, this field shall be present. 
If the evidence is an evidence on a 
notification and the issuer of the evidence 
has access to the details of the sender's 
message this field should be present. If the 
issuer does not have access to the details of 
sender's message this field shall be absent. 
If present, the requirements for its children 
fields are specified in clause clause A. 1 . 1 5. 1 . 
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Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


notif icationMessageDetails 


C 


0..1 


If the evidence is an evidence on a 
notification, this field shall be present. 
If the evidence is not an evidence on a 
notification this field shall be absent. 
If present, the requirements for its children 
fields are specified in clause A.1.15.2. 


transact ionLoglnformat ion 





0..1 




extensions 





0..1 





A.2.7 Evidence AcceptanceRejectionByRecipient 



The table below shows the contents of this element. 



Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


Attribute version 


M 


1 


Value: "i" for this version 


eventCode 


M 


1 


Value if recipient (or recipient's delegate) has 
accepted the message: "Acceptance" 
Value if recipient (or recipient's delegates) 
has rejected the message: "Rejection" . 


eventReasons 


C 


0..1 


If value of eventCode is "Acceptance" 
then this element shall not appear. 
If value of eventCode is "Rejection" then 
one single instance of this element shall 
appear. The values of their eventReason 
children shall contain the codes identifying 
the reason(s) why the message could not be 
retrieved from the mailbox. 


evidence Identifier 


M 


1 


Value as computed by the Evidence issuer. 


evidence I ssuerPol icy ID 





0..1 




evidence I ssuerDetai Is 


M 


1 




recipientAuthenticationDetail 
s 


C 


0..1 


If the recipient (or recipient's delegates) has 
been authenticated by the REM-MD, then 
this element shall be present. Its contents 
will indicate the authentication process 
details. 

If the recipient has not been authenticated by 
the REM-MD, then this element shall not be 
present. 


eventTime 


M 


1 


If recipient (or recipient's delegates) has 
accepted the message this element shall 
contain the acceptance time. 
If recipient (or recipient's delegates) has 
rejected the message this element shall 
contain the rejection time. 


replyTo 





0..1 




senderDetails 


M 


1 




recipient sDetai Is 


M 


1 




recipient sDelegatesDetai Is 


C 


0..1 


If the evidence is generated for delegated 
entities only, then this element shall appear. 
If the evidence is generated for recipients 
only, then this element shall appear. 


evidenceRef ersToRecipient 


C 


0..1 


If the evidence only refers to some 

recipient/delegate then this element shall 

appear. 

If the evidence refers to all the 

recipients/delegates then this element shall 

not appear. 
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Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


senderMessageDetails 


C 


0..1 


If the evidence is not an evidence on a 
notification, this field shall be present. 
If the evidence is an evidence on a 
notification and the issuer of the evidence 
has access to the details of the sender's 
message this field should be present. If the 
issuer does not have access to the details of 
sender's message this field shall be absent. 
If present, the requirements for its children 
fields are specified in clause A.1. 15.1. 


notif icationMessageDetails 


C 


0..1 


If the evidence is an evidence on a 
notification, this field shall be present. 
If the evidence is not an evidence on a 
notification this field shall be absent. 
If present, the requirements for its children 
fields are specified in clause A. 1.1 5. 2. 


transactionLoglnformation 





0..1 




extensions 





0..1 





A.2.8 Evidence RelayToNonREMSystem 

The table below shows the contents of this element. 
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Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


Attribute version 


M 


1 


Value: "i" for this version. 


eventCode 





0..1 


Already identified values for this element: 
Value if message has been forwarded to 
regular e-mail: 

" ForwardedToRegularEMail " 
Value if message has been received from 
regular e-mail: 

"ForwardedToPrintingSystem" . 


evidence Identifier 


M 




Value as computed by the Evidence issuer. 


evidence Issuer Pol icy ID 





0..1 




evidence I ssuerDetai Is 


M 






eventTime 


M 




This element shall contain the message 
forwarding time. 


replyTo 





0..1 




senderDetails 


M 






recipientsDetails 


M 






evidenceRef ersToRecipient 


C 


0..1 


If the evidence only refers to some 

recipient/delegate then this element shall 

appear. 

If the evidence refers to all the 

recipients/delegates then this element 

shall not appear. 


senderMessageDetails 


C 


0..1 


If the evidence is not an evidence on a 
notification, this field shall be present. 
If the evidence is an evidence on a 
notification and the issuer of the evidence 
has access to the details of the sender's 
message this field should be present. If 
the issuer does not have access to the 
details of sender's message this field shall 
be absent. 

If present, the requirements for its children 
fields are specified in clause A.1. 15.1. 


notif icationMessageDetails 


C 


0..1 


If the evidence is an evidence on a 
notification, this field shall be present. 
If the evidence is not an evidence on a 
notification this field shall be absent. 
If present, the requirements for its children 
fields are specified in clause A.I. 15. 2. 


forwardedToExternalSystem 


M 


1 




transact ionLoglnformat ion 





0..1 




Extensions 





0..1 





A.2.9 Evidence ReceivedFromNonREMSystem 

The table below shows the contents of this element. 



Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


Attribute version 


M 




Value: "i" for this version. 


evidence Identifier 


M 




Value as computed by the Evidence issuer. 


evidence I ssuerPol icy ID 





0..1 




evidence I ssuerDetai Is 


M 






eventTime 


M 




This element shall contain the message 
reception time. 


replyTo 





0..1 




senderDetails 


M 






recipientsDetails 


M 
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Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


evidenceRef ersToRecipient 


C 


0..1 


If the evidence only refers to some 

recipient/delegate then this element sliall 

appear. 

If the evidence refers to all the 

recipients/delegates then this element sliall 

not appear. 


messageDetails 


M 


1 


This field shall be present. 

The requirements for its children fields are 

specified in clause A. 1.1 5.1. 


transactionLoglnformation 





0..1 




extensions 





0..1 





ETSI 



57 ETSI TS 1 02 640-2 V2.1 .1 (201 0-01 ) 



Annex B (normative): 

REM-MD Evidence Implementation in xml 

This annex defines the syntax for REM-MD Evidence when xml is used. 

Clause B.l defines the general structure for REM-MD Evidence and provides details for their elements. 

Clause B.2 specifies the different types of REM-MD Evidence as defined in clause 5.1. 

B.1 REM-MD Evidence Structure 

The table below shows the namespaces' URIs and prefixes used throughout the present annex. 



Namespace's URI 


Namespace's prefix 


http : //uri . etsi . org/02 64 0/vl# 


rem 


http://www.w3 . org/2 01/XMLSchema 


xs 


http://www.w3 .org/2 0/0 9/xmldsig# 


ds 


http : //uri . etsi . org/02 2 31/v2# 


tsl 


http://uri.etsi.Org/01903/vl.3.2# 


xades 


urn : oasis : names : tc : dss : 1 . : core : schema 


dss 



Clause 5.2.1 shows a template for REM-MD Evidence. The present clause defines a xml schema for REM-MD 
Evidence. 

<xs : complexType name= " REMEvidenceType " > 
<xs : sequence> 

<xs: element ref ="rem: EventCode" minOccurs="0" /> 

<xs: element ref ="rem: EventReasons" minOccurs="0"/> 

<xs: element name="EvidenceIdentif ier" type="xs : string" /> 

<xs:element name="EvidenceIssuerPolicyID" type="xs : anyURI" minOccurs="0"/> 

<xs : element ref =" rem: EvidenceIssuerDetails"/> 

<xs : element ref =" rem: SenderAuthenticationDetails" minOccurs="0"/> 

<xs : element ref = " rem : RecipientAuthent icat ionDetails " minOccurs= " " /> 

<xs: element name="EventTime" type="xs :dateTime" /> 

<xs: element name="SubmissionTime" type="xs :dateTime" minOccurs="0" /> 

<xs: element name="ReplyTo" type="xs : string" minOccurs="0" /> 

<xs: element ref ="rem: SenderDetails" /> 

<xs:element ref ="rem:RecipientsDetails" /> 

<xs: element ref ="rem:RecipientsDelegatesDetails" minOccurs=" 0" /> 

<xs : element name="EvidenceRef ersToRecipient " type="xs : integer" 
minOccurs="0" /> 

<xs: element ref ="rem: SenderMessageDetails" minOccurs="0" /> 

<xs: element ref ="rem:Notif icationMessageDetails" minOccurs="0" /> 

<xs: element name="ForwardedToExternalSystem" type="xs : string" minOccurs="0" /> 

<xs : element ref = " rem : Transact ionLoglnformat ion" minOccurs= " " / > 

<xs: element ref =" rem: Extensions" minOccurs="0"/> 

<xs:element ref ="ds : Signature" minOccurs="0"/> 
</xs : sequence> 

<xs : attribute name= "version" type="xs : string" use=" required" /> 
<xs :attribute name="Id" type="ID" use="optional"/> 
</xs : complexType > 

Attribute version identifies the version of the evidence syntax. Value for the present specification in "1.2.1". has 
the semantics of data element G04 specified in clause 5.2.2.1.5. 

Attribute Id allows the evidence be referenced from XML documents by an URI. 

Clauses below further develop the elements of a REM-MD Evidence. 
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B.1.1 Element <rem:EventCode> 

This element has the semantics of G02 data element as specified in clause 5.2.2.1.3. Its content is an URL 
The present document has identified a number of events, whose identifiers are defined below. 

"httpiuri .etsi . org/ 02 64 /Event #Acceptance": Acceptance of some REM Message by some 
entity. 

"httpiuri .etsi . org/ 02 640 /Event #Reject ion": Rejection of some REM Message by some 
entity. 

"http :uri . etsi . org/REM/Event#Delivery": Delivery of some REM Message to some entity. 

"http :uri . etsi . org/REM/Event#DeliveryExpiration": Non delivery of some REM Message 
to some entity within a certain period of time. 

"http :uri . etsi . org/REM/Event#Download": Download of some REM Message by recipient or 
recipient's delegate from a REM's REM-MD Repository. 

"httpiuri .etsi . org/REM/Event #DownloadExpiration": No download of some REM 
Message by recipient or recipient's delegate from a REM's REM-MD Repository within a certain period of 
time. 

"httpiuri .etsi . org/REM/Event #Retrieval" : Retrieval of some REM Message by recipient from 
recipient's mailbox. 

"httpiuri .etsi . org/REM/Event#NonRetrievalExpiration": Non retrieval of some REM 
Message by recipient from recipient's mailbox within a certain period of time. 

"http : uri . etsi . org/REM/Event #Rej ection" : Rejection of download of a message by recipient. 

"httpiuri .etsi . org/REM/Event#ForwardedToRegularEMail": Forward of REM Message to 
a regular e-mail system. 

"http :uri . etsi . org/REM/Event#ForwardedToPrintingSystem": Forward of REM Message 
to a printing system to be subsequently sent via physical registered mail. 

"http : uri . etsi . org/REM/Event#ReceivedFromRegularEMail " : Reception of a message 
from a regular e-mail system. 

B.1 .2 Element <rem:EventReasons> 

This element has the semantics of G03 data element as specified in clause 5.2.2.1.4. Below follows the xml schema for 
this element. 

<xs : element name= " EventReasons " type= " rem : EventReasonsType " / > 
<xs : complexType name= " EventReasonsType " > 
<xs : sequence> 

<xs: element ref ="rem: EventReason" maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType > 

<xs: element name=" EventReason" type="rem: EventReasonType"/> 
<xs : complexType name= " EventReasonType " > 
<xs : sequence> 

<xs: element name="Code" type="xs : anyURI"/> 

<xs: element name= "Details" type="xs : string" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType > 

Element <rem: EventReasons > contains a list of <rem: Event Reason> elements. 

<rem : Event Reason>'s <rem : Code> child contains the reason code as an URI. Annex D of the present document 
shows the codes for the reasons identified by the present document. 
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<rem : EventReason>'s <rem : Details > optional child contains a string with additional details. 

B.1 .3 Element <EvidencelssuerPolicylD> 

This element has the semantics of ROl data element as specified in clause 5.2.2.2.1. 

Below follows the xml schema for this element. 

<xs : element name="EvidenceIssuerPolicyID" type="rem: EvidenceIssuerPolicyIDType"/> 
<xs : complexType name="EvidenceIssuerPolicyIDType" > 

<xs : sequence> 

<xs: element name="PolicyID" type="xs : anyURI" maxOccurs= "unbounded" /> 

</xs : sequence> 
</xs : complexType > 

The content of this element is a sequence of URIs each one identifying one of the applicable policies. Should one of 
these policies be identified by an OID, the content of this element shall be an URN generated as specified in 
RFC 3061 [13]. 

B.1 .4 Element <Evidenceldentifier> 

This element has the semantics of GOO data element as specified in clause 5.2.2.1.1. It contains a unique identifier of the 
REM-MD Evidence for the REM-MD Evidence Issuer. 

All the REM-MD Evidence generated by a certain REM-MD Evidence Issuer shall have different identifiers. The 
present document does not specify any further restriction on the values of this element. 

B.1 .5 Element <rem:EvidencelssuerDetails> 

This element has the semantics of R02 data element as specified in clause 5.2.2.2.2. 

Below follows the xml schema for this element. 

<xs : element name="EvidenceIssuerDetails" type="rem: EntityDetailsType"/> 
<xs : complexType name="EntityDetailsType" > 
<xs : sequence> 

<xs: element ref ="rem:NamesPostalAddresses" minOccurs="0" /> 
<xs: element ref ="tsl : ElectronicAddress" minOccurs="0"/> 
<xs:element ref ="rem: Certif IcateDetails" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType > 

<xs : element name= "NamesPostalAddresses " type= " rem : NamesPostalAddressListType " / > 
<xs : complexType name= "NamesPostalAddressListType " > 

<xs : sequence> 

<xs : element ref = " rem : NamePostalAddress " maxOccurs= "unbounded" / > 

</xs : sequence> 
</xs : complexType > 

<xs : element name= "NamePostalAddress " type= " rem : NamePostalAddressType " / > 
<xs : complexType name= "NamePostalAddressType " > 
<xs : sequence> 

<xs:element ref ="rem: EntityName" minOccurs="0"/> 
<xs: element ref ="rem: PostalAddress" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType > 

<xs: element name=" EntityName" type="rem: EntityNameType"/> 
<xs : complexType name="EntityNameType" > 

<xs : sequence> 

<xs: element name="Name" type="xs : string" maxOccurs= "unbounded" /> 

</xs : sequence> 

<xs : attribute ref ="xml : lang" use= "optional "/> 
</xs : complexType > 

<xs : element name=" PostalAddress" type="rem: PostalAddressType"/> 
<xs : complexType name= " PostalAddressType " > 
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<xs : sequence> 

<xs: element name="StreetAddress" type="tsl :NonEmptyString" maxOccurs= "unbounded" /> 

<xs: element name= "Locality" type="tsl :NonEmptyString"/> 

<xs:element name="StateOrProvince" type="tsl :NonEmptyString" minOccurs="0"/> 

<xs: element name="PostalCode" type="tsl :NonEmptyString"/> 

<xs: element name=" Count ryName" type="tsl :NonEmptyString"/> 
</xs : sequence> 

<xs : attribute ref ="xml : lang" use= "optional "/> 
</xs : complexType> 



<xs : element name="Certif icateDetails" type="rem: Certif icateDetailsType"/> 
<xs : complexType name= " Certif icateDetailsType" > 
<xs : choice> 

<xs: element name="X509Certif icate" type="xs :base64Binary"/> 
<xs: element name="CertID" type="xades : CertIDType"/> 
<xs : element ref ="rem: CertIDAndSignature"/> 
</xs : choice> 
</xs : complexType > 



<xs: element name="CertIDAndSignature" type= "rem: Cert IDAndSignatureType" /> 
<xs : complexType name="CertIDAndSignatureType" > 
<xs : sequence> 

<xs : element name="IssuerSerial" type="ds :X509IssuerSerialType"/> 

<xs : element name="tbsCertif icateDigestDetails" type="xades :DigestAlgAndValueType"/> 
<xs : element ref ="rem: CertSignatureDetails"/> 
</xs : sequence> 
</xs : complexType > 

<xs: element name="CertSignatureDetails" type=="rem: CertSignatureDetailsType" /> 
<xs : complexType name= " CertSignatureDetailsType " > 
<xs : sequence> 

<xs : element ref ="ds : SignatureMethod"/> 
<xs : element ref ="ds : SignatureValue"/> 
</xs : sequence> 
</xs : complexType > 



When present, optional <NamesPostalAddresses> element contains a list of <NamePostalAddresss> 
elements. Each <NamePostalAddresss> may contain the entity's name ( <EntityName> element) and/or the 
postal address ( <PostalAddress> element) in a specific language, which is indicated by their optional lang 
attributes. <EntityName> allows for more than one string for the name. <PostalAddress> allows for more than 
one string for indicating details of the street. 

When present, optional <tsl : ElectronicAddress> element contains the entity's electronic address (for instance 
an e-mail address, although not necessarily). 

When present, optional < Cert if icateDetails > element contains the entity's certificate details. These may be one 
of the following: 

• Entity's X509 certificate itself within element <rem:X5 9Certif icate>. 

• Entity's X509 certificate identifier within element <rem : Cert ID>. This is an instance of 
xades : Cert IDType. See TS 101 903 [4] for more details. 

• Entity's X509 certificate identifier with signature value incorporated within 
<rem : Cert IDAndSignature>. Its contents are as indicated below: 

<rem: IssuerSerial> is an instance of <ds :X5 9IssuerSerial> containing the certificate's 
issuer's name and the serial number. See XML Sig for more details. 

<rem: tbsCertif icateDigestDetails> contains the digest algorithm and digest value of the 
to-be-signed field of the user's certificate. 

< rem : Cert S ignatureDe t ai 1 s > contains the signature algorithm and the signature value of the 
user's certificate. 
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B.1 .6 Element <rem:SenderAuthenticationDetails> 

This element has the semantics of 104 data element as specified in clause 5.2.2.3.5. This element, if present indicates the 
method used by sender's REM-MD for authenticating the sender. 

Below follows the xml schema for this element. 

<xs : element name= " SenderAuthent icat ionDetails " type= " rem : AuthenticationDetailsType " /> 
<xs : complexType name= "AuthenticationDetailsType " > 
<xs : sequence> 

<xs:element name="AuthenticationTime" type="xs :dateTime"/> 
<xs: element name="AuthenticationMethod" type="xs : anyURI"/> 

<xs:element name="AdditionalDetails" type="xades : AnyType" minOccurs="0" /> 
</xs : sequence> 
</xs : complexType > 

Element < rem :Authent icat ionTime> indicates the time when the sender was authenticated. 

Element < rem :Authent icat ionMethod> indicates the method used for authenticating the sender. The following 
methods and identifiers have already been identified: 

• "http:uri .etsi . org/REM/AuthMethod#Basic": Basic: Using basic mechanisms such as 
passwords for use of signature. 

• "http : uri . etsi . org/REM/AuthMethod#Enhanced" . Enhanced: Using enhanced authentication 
such two factor mechanisms linked to a one time password. 

• "http : uri . etsi . org/REM/AuthMethod#Strong" . Strong authentication using client certificate via 
mutual SSL. 

• "http : uri . etsi . org/REM/AuthMethod#AdES " . AdES: Using advanced electronic signatures. 

• " http : uri . et si . org/REM/AuthMethod#AdES - Plus " . AdES-Plus: Using advanced electronic 
signatures with Secure Signature Creation Devices (as defined in Directive 1999/93/EC [1]) or equivalent 
secure cryptographic device. 

• "http : uri . etsi . org/REM/AuthMethod#QES " . QES: Using advanced electronic signatures with 
Secure Signature Creation Devices and Qualified Certificates (as defined in Directive 1999/93/EC [1]). 

Optional element <rem :AdditionalDe tails > contains additional details on the authentication process. It may 
contain, for instance, the token presented by the sender to the sender's REM-MD. If the token is the sender's signature 
itself, then it shall appear within a <dss : SignatureObj ect > element defined in the core of the OASIS DSS core 
protocol [12], with the following restrictions: 

• When the sender's signature is a CMS or PKCS#7 signature, the child of this element will be a 
<dss : Base64Signature> encapsulating its BER-encoded value. 

• Should the sender's signature be a XML signature, the child of this element would be a <ds : Signature > 
element. 

• This element shall not have any child different to the ones mentioned in this bulleted list. 

B.1 .7 Element <rem:RecipientAuthenticationDetails> 

This element has the semantics of 105 data element as specified in clause 5.2.2.3.6. This element, if present indicates the 
method used by recipient's REM-MD for authenticating the recipient. 

Below follows the xml schema for this element. 

<xs: element name="RecipientAuthenticationDetails" type=" rem: AuthenticationDetailsType /> 
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B.1.8 Element <rem:EventTime> 

This field has the semantics of G05 data element as specified in clause 5.2.2.1.6. 

B.1 .9 Element <rem:SubmissionTime> 

This field has the semantics of M03 data element as specified in clause 5.2.2.4.4. 

B.1.10 Element <rem:ReplyTo> 

This element has the semantics of MOl data element as specified in clause 5.2.2.4.2. 

B.1 .1 1 Element <rem:SenderDetails> 

This element has the semantics of 100 data element as specified in clause 5.2.2.3.1. 
Below follows the xml schema for this element: 

<xs: element name="SenderDetails" type="rem: EntityDetailsType" /> 

B.1 .1 2 Element <rem:RecipientsDetails> 

This element has the semantics of 101 data element as specified in clause 5.2.2.3.2. 

Below follows the xml schema for this element: 

<xs: element name="RecipientsDetails" type="rem: EntityDetailsListType" /> 
<xs : complexType name= " EntityDetailsListType " > 

<xs : sequence> 

<xs: element name="EntityDetails" type=" rem: EntityDetailsType" maxOccurs= "unbounded" /> 

</xs : sequence> 
</xs : complexType > 

Each <EntityDetails> element contains the details of one of the recipients of the message. 

B.1. 13 Element <rem:RecipientsDelegatesDetails> 

This element has the semantics of 102 data element as specified in clause 5.2.2.3.3. 

Below follows the xml schema for this element: 

<xs: element name="RecipientsDelegatesDetails" type=" rem: Recipient sDelegatesType" /> 
<xs : complexType name= "Recipient sDelegatesType " > 

<xs : sequence maxOccurs= "unbounded" > 
<xs : element ref ="rem:Delegate"/> 

</xs : sequence> 
</xs : complexType > 

<xs:element name= "Delegate" type=" rem: Recipient sDelegateType" /> 
<xs : complexType name= "Recipient sDelegateType " > 

<xs : sequence> 

<xs : element name="DelegateDetails" type="rem:UserDetailsType"/> 

<xs: element name="DelegatingRecipients" type= " rem :ListOf Integers" minOccurs="0"/> 

</xs : sequence> 
</xs : complexType > 
<xs : simpleType name="ListOf Integers" > 

<xs : list itemType="xs : integer"/> 
</xs : simpleType > 

<rem:Delegate>'s <rem: DelegateDetails> element contains the details of the delegate in question. 
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<rem:Delegate>'s <rem: DelegatingRecipients> element contains a list of integers that identify the 
recipients that have delegated in this entity. First Recipient in <rem : Sender sDet ails > is assigned number 1. If 
this element is absent, then the delegate will act as delegated of all the recipients. 

B. 1 . 1 4 Element <EvidenceRefersToRecipient> 

This element has the semantics of 103 data element as specified in clause 5.2.2.3.4. Its value references one of the 
recipients in <rem: RecipientsDetails> element. First recipient in the list of recipients is assigned number 1. 

B. 1 . 1 5 Elements <rem :senderMessageDetails> and 
<rem:notificationMessageDetails> 

Elements <rem: senderMessageDetails> and <rem : not if icationMes sageDe tails > are instances of 
Me ssageDe tails type, whose xml schema is shown below: 

<xs : complexType name="MessageDetailsType" > 
<xs : sequence> 

<xs: element name="MessageSubject " type="xs : string" minOccurs="0" /> 

<xs: element name="UAMessageIdentif ier" type="xs : string" minOccurs="0"/> 

<xs: element name="MessageIdentif ierByREMMD" type="xs : string" /> 

<xs: element ref ="ds :DigestMethod" minOccurs="0"/> 

<xs:element ref ="ds :DigestValue" minOccurs="0"/> 
</xs : sequence> 

<xs rattribute name="isNotif ication" type="xs : boolean" use="optional"/> 
</xs : complexType > 

Optional attribute isNot if ication indicates whether the details corresponds to notification (a message containing a 
pointer to the sender's message) or not. Absence of this attribute means that the message is not a notification. 

If present, optional <rem : MessageSub j ect > element contains the value of the Subject field of the message. 

If present, optional <rem : UAMessageldentif ier> element contains an identifier as computed by the user's UA. 

Element <rem : Me s sage Ident if ierByREMMD > contains an identifier computed by a REM-MD. This identifier 
shall be unique for this REM-MD. 

Finally, <ds : DigestMethod> and <ds : DigestValue> optional elements contain, when they are present, the 
message's digest algorithm identifier and the digest value computed on the sender's message respectively. 

B. 1.1 5.1 Element <rem:senderMessageDetails> 

Element <rem: senderMessageDetails> has the semantics of MOO data element as specified in clause 5.2.2.4.1 
when it contains details of the sender's message. As it has been said before this field is an instance of 
Me ssageDe tails type. Below follows its XML schema definition: 

<xs : element name= " SenderMessageDetails " type= " rem : MessageDetailsType " / > 

Evidence not reporting events on notifications shall contain the <rem : SenderMessageDetails > element. 
When this element is present in an evidence, the following requirements apply to their children and attributes: 

• Attribute I sNot i f i cat ion may be present (in which case its value shall be " f al se " ) or not (as absence 
of this attribute means that the details do not correspond to a notification). 

• Element < rem: Me ssageSubject> shall be present. 

• Element <rem:UAMessageIdentif ier > may be present. 

• Element <rem:MessageIdentif ierByREMMD > shall be present. 
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• Elements <ds : DigestMethod> and <ds : DigestValue> shall be present. 

B. 1.1 5. 2 Element <rem:notificationMessageDetails> 

Element <rem: not if icationMes sageDe tails > has the semantics of MOO data element as specified in clause 
5.2.2.4.1 when it contains the details of a notification (a message containing a pointer to the sender's message). This 
field is an instance of MessageDetails type. Below follows its XML schema definition: 

<xs : element name="Notif icationMessageDetails" type="rem:MessageDetailsType"/> 

Evidence reporting events on notifications shall contain the <rem : not if icationMes sageDe tails > element. In 
addition, if evidence issuers have access to the sender's message details, then these evidence should also contain the 

<rem: senderMe s sageDe t ails > element. 

When this element is present in an evidence, the following requirements apply to their children and attributes: 

• Attribute IsNotif ication shall be present and its value shall be " true " . 

• Element < rem: Me ssageSubject> shall be absent. 

• Element <rem:UAMessageIdentifier> shall be absent. 

• Element <rem:MessageIdentifierByREMMD> shall be present. 

• Elements <ds : DigestMethod> and <ds : DigestValue> shall be present. 

B.1 .16 Element <rem:ForwardedToExternalSystem> 

This element the semantics of M04 data element as specified in clause 5.2.2.4.5. 

B.1.17 Element <rem:TransactionLoglnformation> 

This element has the semantics of G06 data element as specified in clause 5.2.2.2.3. This element is a placeholder that 
issuers of evidence may use for including pieces of the log file content within them. 

Below follows the xml schema for this element. 

<xs : element name="TransactionLogInf ormation" type="rem:TransactionLogInf ormationType"/> 
<xs : complexType name= " Transact ionLoglnformat ionType" > 

<xs : sequence> 

<xs : element ref= "rem: Transact ionLog" maxOccurs= "unbounded" /> 

</xs : sequence> 
</xs : complexType > 
<xs: element name=" Transact ionLog" type="xades : AnyType"/> 

Element <rem : Transact ionLoglnformat ion> contains a sequence of <rem : Transact ionLog> elements, 
each one containing an instance of log information. 

The present document does not mandate any particular format for the content of <rem : Transact ionLog > 
elements. 

B.1.18 Element <rem:Extensions> 

This element has the semantics of Enn data element. This element is a placeholder for further standardized or private 
extensions. 
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Below follows the xml schema for this element. 

<xs : element name=" Extensions" type="rem: ExtensionsListType"/> 
<xs : complexType name="ExtensionsListType" > 

<xs : sequence maxOccurs= "unbounded" > 
<xs : element ref =" rem: Extension" /> 

</xs : sequence> 
</xs : complexType > 

<xs: element name=" Extension" type="rem: ExtensionType"/> 
<xs : complexType name="ExtensionType" > 
<xs : complexContent> 

<xs : extension base="xades :AnyType"> 

<xs rattribute name="isCritical" type="xs : boolean" use="optional"/> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType > 

This element contains a list of extensions. 

Each extension in an evidence is designated as either critical or non-critical bytheisCritical boolean attribute. If 
this attribute is absent, then the extension is designated as non critical. 

An extension using system shall reject the evidence if it encounters a critical extension it does not recognize. A 
non-critical extension may be ignored if it is not recognized. 



B.1.19 Element <ds:Signature> 



This element has the semantics of R03 data element as specified in clause 5.2.2.2.3. Should this element be present, it 
will contain the enveloped signature of the Evidence, profiled as indicated in clause 6. 



B.2 REM-MD Evidence 

This clause defines formats for different types of Evidence, which are listed in the xml schema below. 

<xs:element name="SubmissionAcceptanceRejection" type="rem:REMEvidenceType" /> 

<xs: element name="RelayREMMDAcceptanceRejection" type="rem:REMEvidenceType" /> 

<xs: element name="RelayREMMDFailure" type="rem:REiyiEvidenceType" /> 

<xs : element name="DeliveryNonDeliveryToRecipient" type="rem:REMEvidenceType"/> 

<xs : element name= "DownloadNonDownloadByRecipient " type= " rem : REMEvidenceType " / > 

<xs : element name="RetrievalNonRetrievalByRecipient" type=" rem: REMEvidenceType "/> 

<xs : element name= " AcceptanceRe j ect ionByRecipient " type= " rem : REMEvidenceType " / > 

<xs : element name= " RelayToNonREMSystem" type= " rem : REMEvidenceType " / > 

<xs : element name= " ReceivedFromNonREMSystem" type= " rem : REMEvidenceType " / > 

Each clause below specifies one Evidence type by profiling the contents of the REMEvidenceType shown above. 
Constraints are expressed in tables organized as follows: 

• Column Element/Attribute identifies the profiled element or attribute. Should an evidence could carry more 
than one instance of the same element, then the usual array syntax of an integer index within square brackets is 
used for enumerating the different instances. Array index numbering starts at 1. 

• Column Mandatory/Optional specifies requirements on the element/attribute. The following codes may 
appear: 

M: This means that the element/attribute is mandatory. 

O: This means that presence or absence of the element/attribute is optional. 

C: This means that the presence of the element/attribute depends on certain conditions that are further 
developed in column Additional Profile Properties. 

• Column Nbr. Occurrences identifies the number of occurrences of the element. 
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• Column Additional Profile Properties specifies additional requirements on the element/attribute: values, 
conditions, etc. Terms shall, may and should used in these cells have the meaning as specified in 
TS 102 904 [16]. 

B.2. 1 Evidence <SubmissionAcceptanceRejection> 

The table below shows the contents of this element. 



Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


Attribute version 


M 


1 


Value: "2" for this version 


rem:EventCode 


M 


1 


Value if acceptance: "Acceptance" 
Value if rejection: "Rejection" . 


rem : EventReasons 


C 


0..1 


If value of rem : EventCode is 

"Acceptance" then this element shall not 

appear. 

If value of rem : EventCode is 

"Rejection" then one single instance of 

this element shall appear. The values of 

their rem : EventReason children shall 

contain the codes identifying the reason(s) 

why the 

REM-MD rejected the message submitted by 

the sender. 


rem: EvidencelssuerPolicylD 





0..1 




rem: Evidenceldentif ier 


M 


1 


Value as computed by the Evidence issuer. 


rem: EvidencelssuerDetails 


M 


1 




rem:SenderAuthenticationDetails 


C 


0..1 


If the sender has been authenticated by the 

REM-MD, then this element shall be 

present. Its contents will indicate the 

authentication process details. 

If the sender has not been authenticated by 

the REM-MD, then this element shall not be 

present. 


rem:EventTime 


M 


1 




rem: SubmissionTime 


M 


1 




replyTo 





0..1 




rem: SenderDetails 


M 


1 




rem:RecipientsDetails 


M 


1 




rem:RecipientsDelegatesDetails 


C 


0..1 


If the evidence is generated for delegated 
entities only, then this element shall appear. 
If the evidence is generated for recipients 
only, then this element shall not appear. 


rem: SenderMessageDetails 


M 


1 


This element shall be present. 
The requirements for its attributes and 
children elements are specified in 
clause B. 1.15.1. 


rem : TransactionLogInf ormation 





0..1 




rem : Extensions 





0..1 




ds : Signature 


C 


0..1 





ETSI 



67 



ETSI TS 102 640-2 V2.1.1 (2010-01) 



B.2.2 Evidence <RelayREMMDAcceptanceRejection> 

The table below shows the contents of this element. 



Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


Attribute version 


M 


1 


Value: "2" for this version. 


rem:EventCode 


M 


1 


Value if acceptance by receiving 

REM-MD: "Acceptance" 

Value if rejection by receiving REM-MD: 

"Rejection" 


rem : EventReasons 


C 


0..1 


If value of rem : EventCode is 
"Acceptance" then this element sliall 
not appear. 

If value of rem : EventCode is 
"Rejection" then one single instance of 
this element shall appear. The values of 
their rem : EventReason children shall 
contain the codes identifying the reason(s) 
why the REM-MD rejected the message to 
be relayed. 


rem: Evidenceldentif ier 


M 


1 


Value as computed by the Evidence issuer. 


rem: EvidencelssuerPolicylD 





0..1 




rem: EvidencelssuerDetails 


M 


1 




rem:EventTime 


M 


1 


If recipient's REM-MD has accepted the 
message this element shall indicate when 
the acceptance occurred. 
If recipient's REM-MD has rejected the 
message this element shall indicate when 
the rejection occurred. 


replyTo 





0..1 




rem: SenderDetails 


M 


1 




rem:RecipientsDetails 


M 


1 




rem:RecipientsDelegatesDetails 


C 


0..1 


If the evidence is generated for delegated 

entities only, then this element shall 

appear. 

If the evidence is generated for recipients 

only, then this element shall not appear. 


rem : EvidenceRef ersToRecipient 


C 


0..1 


If the evidence only refers to some 

recipient/delegate then this element shall 

appear. 

If the evidence refers to all the 

recipients/delegates then this element 

shall not appear. 


rem : SenderMessageDetails 


C 


0..1 


If the evidence is not an evidence on a 
notification, this element shall be present. 
If the evidence is an evidence on a 
notification and the issuer of the evidence 
has access to the details of the sender's 
message this element should be present. 
If the issuer does not have access to the 
details of sender's message this element 
shall be absent. 

If present, the requirements for its children 
elements and attributes are specified in 
clause B. 1.15.1. 


rem:Notif icationMessageDetails 


C 


0..1 


If the evidence is an evidence on a 
notification, this element shall be present. 
If the evidence is not an evidence on a 
notification this element shall be absent. 
If present, the requirements for its 
attributes and children elements are 
specified in clause B.I. 15. 2. 


rem : TransactionLogInf ormation 





0..1 




rem : Extensions 





0..1 




ds : Signature 


C 


0..1 
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B.2.3 Evidence <RelayREMMDFailure> 

The table below shows the contents of this element. 



Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


Attribute version 


M 


1 


Value: "2" for this version. 


rem: Event Code 


M 


1 


For this evidence the value of this code is 
always: "DeliveryExpiration" 


rem : EventReasons 


M 


1 


The values of their rem : EventReason 
children shall contain the codes identifying 
the reason(s) why the sending REM-MD 
could not delivery the message to the 
receiving REM-MD. 


rem: Evidenceldentif ier 


M 


1 


Value as computed by the Evidence issuer. 


rem: EvidencelssuerPolicylD 





0..1 




rem: EvidencelssuerDetails 


M 


1 




rem:EventTime 


M 


1 


This element will contain the message 
delivery expiration time. 


replyTo 





0..1 




rem: SenderDetails 


M 


1 




rem:RecipientsDetails 


M 


1 




rem:RecipientsDelegatesDetails 


C 


0..1 


If the evidence is generated for delegated 
entities only, then this element shall appear. 
If the evidence is generated for recipients 
only, then this element shall appear. 


rem : EvidenceRef ersToRecipient 


C 


0..1 


If the evidence only refers to some 

recipient/delegate then this element shall 

appear. 

If the evidence refers to all the 

recipients/delegates then this element shall 

not appear. 


rem: SenderMessageDetails 


C 


0..1 


If the evidence is not an evidence on a 
notification, this element shall be present. 
If the evidence is an evidence on a 
notification and the issuer of the evidence 
has access to the details of the sender's 
message this element should be present. If 
the issuer does not have access to the 
details of sender's message this element 
shall be absent. 

If present, the requirements for its children 
elements and attributes are specified in 
clause B. 1.15.1. 


rem:Notif icationMessageDetails 


C 


0..1 


If the evidence is an evidence on a 
notification, this element shall be present. 
If the evidence is not an evidence on a 
notification this element shall be absent. 
If present, the requirements for its attributes 
and children elements are specified in 
clause B.I. 15. 2. 


rem : TransactionLogInf ormation 





0..1 




rem : Extensions 





0..1 




ds: Signature 


C 


0..1 
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B.2.4 Evidence <DeliveryNonDeliveryToRecipient> 



The table below shows the contents of this element. 



Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


Attribute version 


M 


1 


Value: "i" for this version. 


rem:EventCode 


M 


1 


Value if message ( which may be a 
notification) has been delivered to recipient or 
recipient's delegates: "Delivery" 
Value if message (which may be a 
notification) has not been delivered to 
recipient or recipient's delegates: 
"DeliveryExpiration" 


rem : EventReasons 


C 


0..1 


If value of rem:EventCode is "Delivery" 
then this element shall not appear. 
If value of rem : EventCode is 
"DeliveryExpiration" then one single 
instance of this element shall appear. The 
values of their rem : EventReason children 
shall contain the codes identifying the 
reason(s) why the message could not be 
delivered to the recipient or the recipient's 
delegates. 


rem: Evidence Identifier 


M 


1 


Value as computed by the Evidence issuer. 


rem: EvidencelssuerPolicylD 





0..1 




rem: EvidencelssuerDetails 


M 


1 




rem : RecipientAuthenticationDetai 
Is 


C 


0..1 


If the recipient has been authenticated by the 

REM-MD, then this element shall be present. 

Its contents will indicate the authentication 

process details. 

If the recipient has not been authenticated by 

the REM-MD, then this element shall not be 

present. 


rem:EventTime 


M 


1 


If message ( which may be a notification) has 
been delivered to recipient or recipient's 
delegates then this element will contain the 
delivery time. 

If message (which may be a notification) has 
not been delivered to recipient or recipient's 
delegates before the arrival of the delivery 
expiration time, then this element will contain 
the delivery expiration time. 


replyTo 





0..1 




rem: SenderDetails 


M 


1 




rem :RecipientsDet ails 


M 


1 




rem:RecipientsDelegatesDetails 


C 


0..1 


If the evidence is generated for delegated 
entities only, then this element shall appear. 
If the evidence is generated for recipients 
only, then this element shall appear. 


rem : EvidenceRef ersToRecipient 


C 


0..1 


If the evidence only refers to some 

recipient/delegate then this element shall 

appear. 

If the evidence refers to all the 

recipients/delegates then this element shall 

not appear. 
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Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


rem: SenderMessageDetails 


C 


0..1 


If the evidence is not an evidence on a 
notification, this element shall be present. 
If the evidence is an evidence on a 
notification and the issuer of the evidence 
has access to the details of the sender's 
message this element should be present. If 
the issuer does not have access to the 
details of sender's message this element 
shall be absent. 

If present, the requirements for its children 
elements and attributes are specified in 
clause B. 1.15.1. 


rem:Notif icationMessageDetails 


C 


0..1 


If the evidence is an evidence on a 
notification, this element shall be present. 
If the evidence is not an evidence on a 
notification this element shall be absent. 
If present, the requirements for its attributes 
and children elements are specified in clause 
B.I. 15.2. 


rem : TransactionLogInf ormation 





0..1 




rem : Extensions 





0..1 




ds : Signature 


c 


0..1 





B.2.5 Evidence <DownLoadNonDownloadByRecipient> 

The table below shows the contents of this element. 



Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


Attribute version 


M 


1 


Value: "i" for this version. 


rem:EventCode 


M 


1 


Value if message has been downloaded by 
the recipient (or recipient's delegates) from a 
REM-MD's REM-MD Repository: 
"Download" 

Value if message has not been downloaded 
by the recipient or recipient's delegates 
before a certain giving time: 
"DownloadExpiration" . 


rem : EventReasons 


C 


0..1 


If value of rem:EventCode is "Download" 
then this element shall not appear. 
If value of rem : EventCode is 
"DownloadExpiration" then one single 
instance of this element shall appear. The 
values of their rem : EventReason children 
shall contain the codes identifying the 
reason(s) why the message could not be 
downloaded by the recipient or the recipient's 
delegates. 


rem: Evidenceldentif ier 


M 


1 


Value as computed by the Evidence issuer. 


rem: EvidencelssuerPolicylD 





0..1 




rem: EvidencelssuerDetails 


M 


1 




rem:RecipientAuthentionDetails 


C 


0..1 


If the recipient (or recipient's delegates) has 
been authenticated by the REM-MD, then this 
element shall be present. Its contents will 
indicate the authentication process details. 
If the recipient has not been authenticated by 
the REM-MD, then this element shall not be 
present. 
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Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


rem:EventTime 


M 


1 


If message (which may be a notification) has 
been downloaded by the recipient or 
recipient's delegates then this element will 
contain the download time. 
If message (which may be a notification) has 
not been downloaded by the recipient or 
recipient's delegates before the arrival of the 
download expiration time, then this element 
will contain the download expiration time. 


replyTo 





0..1 




rem: SenderDetails 


M 


1 




rem: Recipient sDetai Is 


M 


1 




rem: Recipient sDelegatesDetai Is 


C 


0..1 


If the evidence is generated for delegated 
entities only, then this element shall appear. 
If the evidence is generated for recipients 
only, then this element shall appear. 


rem : EvidenceRef ersToRecipient 


C 


0..1 


If the evidence only refers to some 

recipient/delegate then this element shall 

appear. 

If the evidence refers to all the 

recipients/delegates then this element shall 

not appear. 


rem: SenderMessageDetails 


M 


1 


This element shall be present. 
The requirements for its attributes and 
children elements are specified in 
clause B. 1.15.1. 


rem : TransactionLogInf ormation 





0..1 




rem : Extensions 





0..1 




Ds : Signature 


C 


0..1 
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B.2.6 Evidence <RetrievalNonRetrievalByRecipient> 



The table below shows the contents of this element. 



Element/Attribute 


Mand. 
Opt. 


Number 

occurrence 

s 


Additional requirements 


Attribute version 


M 


1 


Value: "i" for this version. 


rem: Event Code 


M 


1 


Value if message has been retrieved from 
mailbox: "Retrieval" 
Value if message has not been retrieved 
from mailbox before a giving time: 

"RetrievalExpiration" . 


rem : EventReasons 


C 


0..1 


If value of rem : EventCode is 

"Retrieval " then this element shall 

not appear. 

If value of rem : EventCode is 

"RetrievalExpiration" then one 

single instance of this element shall 

appear. The values of their 

rem : EventReason children shall 

contain the codes identifying the 

reason(s) why the message could not be 

retrieved from the mailbox. 


rem: Evidenceldentif ier 


M 


1 


Value as computed by the Evidence 
issuer. 


rem: EvidencelssuerPolicylD 





0..1 




rem: EvidencelssuerDetails 


M 


1 




rem:RecipientAuthenticationDetails 


C 


0..1 


If the recipient (or recipient's delegates) 
has been authenticated by the REM-MD, 
then this element shall be present. Its 
contents will indicate the authentication 
process details. 
If the recipient has not been 
authenticated by the REM-MD, then this 
element shall not be present. 


rem:EventTime 


M 


1 


If message (which may be a notification) 
has been retrieved by the recipient or 
recipient's delegates from mailbox then 
this element shall contain the retrieval 
time. 

If message (which may be a notification) 
has not been retrieved by the recipient or 
recipient's delegates from mailbox then 
this element shall contain the retrieval 
expiration time. 


replyTo 





0..1 




rem: SenderDetails 


M 


1 




rem:RecipientsDetails 


M 


1 




rem:RecipientsDelegatesDetails 


C 


0..1 


If the evidence is generated for delegated 

entities only, then this element shall 

appear. 

If the evidence is generated for recipients 

only, then this element shall appear. 


rem : EvidenceRef ersToRecipient 


C 


0..1 


If the evidence only refers to some 

recipient/delegate then this element shall 

appear. 

If the evidence refers to all the 

recipients/delegates then this element 

shall not appear. 
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Element/Attribute 


Mand. 
Opt. 


Number 

occurrence 

s 


Additional requirements 


rem : SenderMessageDetails 


C 


0..1 


If the evidence is not an evidence on a 
notification, this element shall be present. 
If the evidence is an evidence on a 
notification and the issuer of the evidence 
has access to the details of the sender's 
message this element should be present. 
If the issuer does not have access to the 
details of sender's message this element 
shall be absent. 

If present, the requirements for its 
children elements and attributes are 
specified in clause B. 1.1 5.1. 


rem:Notif icationMessageDetails 


C 


0..1 


If the evidence is an evidence on a 
notification, this element shall be present. 
If the evidence is not an evidence on a 
notification this element shall be absent. 
If present, the requirements for its 
attributes and children elements are 
specified in clause B.I. 15. 2. 


rem:TransactionLogInformation 





0..1 




rem : Extensions 





0..1 




ds : Signature 


c 


0..1 





B.2.7 Evidence <AcceptanceRejectionByRecipient> 

The table below shows the contents of this element. 



Element/Attribute 


Mand. 
Opt. 


Number 

occurrenc 

es 


Additional requirements 


Attribute version 


M 


1 


Value: "i" for this version. 


rem:EventCode 


M 


1 


Value if recipient (or recipient's delegate) 

has accepted the message: 

"Acceptance" 

Value if recipient (or recipient's delegates) 

has rejected the message: "Rejection" . 


rem : EventReasons 


C 


0..1 


If value of rem : EventCode is 
"Acceptance" then this element shall 
not appear. 

If value of rem : EventCode is 
"Rejection" then one single instance of 
this element shall appear. The values of 
their rem : EventReason children shall 
contain the codes identifying the reason(s) 
why the message could not be retrieved 
from the mailbox. 


rem: Evidenceldentif ier 


M 


1 


Value as computed by the Evidence issuer. 


rem: EvidencelssuerPolicylD 





0..1 




rem: EvidencelssuerDetails 


M 


1 




rem:RecipientAuthenticationDetails 


C 


0..1 


If the recipient (or recipient's delegates) 
has been authenticated by the REM-MD, 
then this element shall be present. Its 
contents will indicate the authentication 
process details. 

If the recipient has not been authenticated 
by the REM-MD, then this element shall 
not be present. 
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Element/Attribute 


Mand. 
Opt. 


Number 

occurrenc 

es 


Additional requirements 


rem:EventTime 


M 


1 


If recipient (or recipient's delegates) has 
accepted the message this element shall 
contain the acceptance time. 
If recipient (or recipient's delegates) has 
rejected the message this element shall 
contain the rejection time. 


replyTo 





0..1 




rem: SenderDetails 


M 


1 




rem: Recipient sDetai Is 


M 


1 




rem:RecipientsDelegatesDetails 


C 


0..1 


If the evidence is generated for delegated 

entities only, then this element shall 

appear. 

If the evidence is generated for recipients 

only, then this element shall appear. 


rem : EvidenceRef ersToRecipient 


C 


0..1 


If the evidence only refers to some 

recipient/delegate then this element shall 

appear. 

If the evidence refers to all the 

recipients/delegates then this element 

shall not appear. 


rem: senderMessageDetails 


C 


0..1 


If the evidence is not an evidence on a 
notification, this element shall be present. 
If the evidence is an evidence on a 
notification and the issuer of the evidence 
has access to the details of the sender's 
message this element should be present. 
If the issuer does not have access to the 
details of sender's message this element 
shall be absent. 

If present, the requirements for its children 
elements and attributes are specified in 
clause B. 1.15.1. 


rem:notif icationMessageDetails 


C 


0..1 


If the evidence is an evidence on a 
notification, this element shall be present. 
If the evidence is not an evidence on a 
notification this element shall be absent. 
If present, the requirements for its 
attributes and children elements are 
specified in clause B.I. 15. 2. 


rem : TransactionLogInf ormation 





0..1 




rem: Extensions 





0..1 




ds : Signature 


C 


0..1 





B.2.8 Evidence <RelayToNonREMSystenn> 

The table below shows the contents of this element. 



Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


Attribute version 


M 


1 


Value: "i" for this version. 


rem:EventCode 





0..1 


Already identified values for this element: 
Value if message has been forwarded to 
regular e-mail: 

" ForwardedToRegularEMail " 
Value if message has been received from 
regular e-mail: 

"ForwardedToPrintingSystem" . 


rem: Evidenceldentif ier 


M 


1 


Value as computed by the Evidence issuer. 


rem: EvidencelssuerPolicylD 





0..1 




rem: EvidencelssuerDetails 


M 


1 




rem:EventTime 


M 


1 


This element shall contain the message 
forwarding time. 
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Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


replyTo 





0..1 




rem: SenderDetails 


M 


1 




rem: Recipient sDetai Is 


M 


1 




rem : EvidenceRef ersToRecipient 


C 


0..1 


If the evidence only refers to some 

recipient/delegate then this element shall 

appear. 

If the evidence refers to all the 

recipients/delegates then this element 

shall not appear. 


rem: SenderMessageDetails 


C 


0..1 


If the evidence is not an evidence on a 
notification, this element shall be present. 
If the evidence is an evidence on a 
notification and the issuer of the evidence 
has access to the details of the sender's 
message this element should be present. 
If the issuer does not have access to the 
details of sender's message this element 
shall be absent. 

If present, the requirements for its children 
elements and attributes are specified in 
clause B. 1.15.1. 


rem:Notif icationMessageDetails 


C 


0..1 


If the evidence is an evidence on a 
notification, this element shall be present. 
If the evidence is not an evidence on a 
notification this element shall be absent. 
If present, the requirements for its 
attributes and children elements are 
specified in clause B.I. 15. 2. 


rem: ForwardedToExternalSystem 


M 


1 




rem : TransactionLogInf ormation 





0..1 




rem : Extensions 





0..1 




ds : Signature 


C 


0..1 





B.2.9 Evidence <ReceivedFromNonREMSystem> 



The table below shows the contents of this element. 



Element/Attribute 


Mand. 
Opt. 


Number 
occurrences 


Additional requirements 


Attribute version 


M 


1 


Value: "i" for this version. 


rem: Evidenceldentif ier 


M 


1 


Value as computed by the Evidence issuer. 


rem: EvidencelssuerPolicylD 





0..1 




rem: EvidencelssuerDetails 


M 


1 




rem:EventTime 


M 


1 


This element shall contain the message 
reception time. 


replyTo 





0..1 




rem: SenderDetails 


M 


1 




rem: Recipient sDetai Is 


M 


1 




rem : EvidenceRef ersToRecipient 


C 


0..1 


If the evidence only refers to some 

recipient/delegate then this element shall 

appear. 

If the evidence refers to all the 

recipients/delegates then this element 

shall not appear. 


rem: SenderMessageDetails 


M 


1 


This element shall be present. 
The requirements for its attributes and 
children elements are specified in 
clause B.I. 15.1. 


rem : TransactionLogInf ormation 





0..1 




rem : Extensions 





0..1 




ds : Signature 


C 


0..1 





ETSI 



76 ETSI TS 1 02 640-2 V2.1 .1 (201 0-01 ) 



Annex C (normative): 

REM-MD Evidence Implementation in PDF 

This annex specifies mechanisms for generating human readable REM-MD Evidence based in PDF documents. 
For generating REM-MD Evidence in PDF the following process is recommended: 

1) Generate the REM-MD Evidence using the XML syntax as indicated in annex B. 

2) Generate an XFA file where the XML data object is the XML-encoded REM-MD Evidence generated in 
step L 

3) Generate a PDF/A-1 file from the XFA generated in step 2. This format is suitable for long term preservation 
of the information. 

4) Should the REM-MD Evidence be signed, sign the PDF/A-1 file generated in step 3 using PDF signatures as 
specified in clause 6.3.3 

NOTE: The XFA forms architecture may be used to create PDF documents mapping the XML data to PDF form 
fields. It is recommended that the XFA template maps the XML data element names directly to form 
fields with equivalent names and that PDF includes text associated with the form fields describing the 
meaning of each field in an appropriate language. 
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Annex D (normative): 

Event reason identifiers and codes 



Element <rem : Event Re as on > in XML evidence and field event Re a son in ASN.l identify the event reason. In 
XML evidence the content of the element is an URL In ASN.l evidence the field is an integer. 

The table below lists all the event reasons identified in the present document, and shows the correspondence between 
the URI and the integer values. 



Identifier as URI 


Ident. as integer 


http : uri . etsi . org/REM/EventReasonttlnvalidMessageFormat 


1 


http : uri . etsi . org/REM/EventReasonttMalwareFound 


2 


http : uri . etsi . org/REM/EventReasonftlnvalidUserSignature 


3 


http : uri . etsi . org/REM/EventReasonttUserCertExpiredOrRevoked 


4 


http : uri . etsi . org/REM/EventReason#PolicyViolation 


5 


http:uri.etsi.0rg/REM/EventReason#R REMMD Malfunction 


6 


http : uri . etsi . org/REM/EventReason#R_REMMD_NotIdenif ied 


7 


http:uri.etsi.0rg/REM/EventReason#R REMMD Unreachable 


8 


http:uri.etsi.0rg/REM/EventReason#S REMMD ReceivedNoDeliverylnfoFromR REMMD 


9 


http : uri . etsi . org/REM/EventReason#UnknownRecipient 


10 


http : uri . etsi . org/REM/EventReason#MailboxFull 


11 


http : uri . etsi . org/REM/EventReason#TechnicalMalf unction 


12 


http : uri . etsi . org/REM/EventReason#AttachementFormatNotAccepted 


13 


http : uri . etsi . org/REM/EventReason#RecipientRe j ection 


14 


http : uri . etsi . org/REM/EventReason#RetentionPeriodExpired 


15 


http : uri . etsi . org/REM/EventReason#RegularEmailUnreachable 


16 


http : uri . etsi . org/REM/EventReason#RegularEmailNonOperational 


17 


http : uri . etsi . org/REM/EventReason#RegularEmailRe j ection 


18 


http : uri . etsi . org/REM/EventReason#PrintingSystemUnreachable 


19 


http : uri . etsi . org/REM/EventReason#PrintingSystemNonOperational 


20 


http : uri . etsi . org/REM/EventReason#PrintingBuf f erFull 


21 


http : uri . etsi . org/REM/EventReason#Other 


22 
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Annex E (normative): 

ASN.1 module for Evidence encoded in ASN.1 

ETSI-REM-vl-88syntax { itu-t(O) identif ied-organization (4) etsi(O) 

tsl-specif ication (1234) id-mod(O) vl-88syntax (1) } 
DEFINITIONS EXPLICIT TAGS ::= 

BEGIN 

-- EXPORTS All 
IMPORTS 

-- Internet X.509 Public Key Infrastructure - Certificate and CRL Profile: RFC 5280 
Extensions 

FROM PKIXlExplicit88 { iso(l) identif ied-organization (3 ) dod(6) internet (1) 
security (5) mechanisms (5) pk:ix(7) id-mod(O) id-pkixl-explicit (18) } 
-- Cryptographic Message Syntax (CMS) : RFC 3 852 
Contentlnfo 

FROM CryptographicMessageSyntax2 04 { iso(l) member -body (2) us (840) rsadsi (113549) 
pkcs(l) pkcs-9(9) smime(16) modules (0) cms-2004(24) } 
-- Provision of harmonized Trust-service status information (TSL) - ETSI TS 102 231 V2 . 1 . 1 
NonEmptyURI, Mult iLangSt ring, MultiLangAddress, ElectronicAddresses, LanguageTag, Count ryCode 
FROM ETSI-TSL-v2-88syntax { itu-t(O) identif ied-organization (4 ) etsi(O) 
tsl-specif ication (2231) id-mod(O) v2-88syntax (1) } 
-- AFNOR - AuthorizedCertif icate 
AuthorizedCertif icate 

FROM EEvidenceCommon { iso(l) member -body (2) fr(250) type-org(l) 

aFNORStandardisation(127) letter (26) standard (74600) asnl-modules (3) common (0) } 

id-rem OBJECT IDENTIFIER ::= { ETSI-REM-vl-88syntax } 

id-rem-evidenceTypes OBJECT IDENTIFIER ::= { id-rem 1 } 

id-rem-evidenceTypes-sumbmissionAcceptanceRejection OBJECT IDENTIFIER ::= { id-rem-evidenceTypes 1 } 
-- OID for SubmissionAcceptanceRejection evidence as specified in 5.1.1 

id-rem-evidenceTypes-relayREMMDAcceptanceRejection OBJECT IDENTIFIER ::= { id-rem-evidenceTypes 2 } 
-- OID for RelayREMMDAcceptanceRejection evidence as specified in 5.1.2 

id-rem-evidenceTypes-relayREMMDFailure OBJECT IDENTIFIER ::= { id-rem-evidenceTypes 3 } -- OID for 
RelayREMMDFailure evidence as specified in 5.1.3 

Id-rem-evidenceTypes-deliveryNonDeliveryToRecipient OBJECT IDENTIFIER ::= { id-rem-evidenceTypes 4 } 
-- OID for DeliveryNonDeliveryToRecipient evidence as specified in 5.1.4 

Id-rem-evidenceTypes-downloadNonDownloadByRecipient OBJECT IDENTIFIER ::= { id-rem-evidenceTypes 5 } 
-- OID for DownloadNonDownloadByRecipient evidence as specified in 5.1.5 

id-rem-evidenceTypes-retrievalNonRetrievalByRecipient OBJECT IDENTIFIER ::= { id-rem-evidenceTypes 6 
} -- OID for RetrievalNonRetrievalByRecipient evidence as specified in 5.1.6 

Id-rem-evidenceTypes-acceptanceRejectionByRecipient OBJECT IDENTIFIER ::= { id-rem-evidenceTypes 7 } 
-- OID for AcceptanceRejectionByRecipient evidence as specified in 5.1.7 

id-rem-evidenceTypes-relayToNonREMSystem OBJECT IDENTIFIER ::= { id-rem-evidenceTypes 8 } -- OID for 
RelayToNonREMSystem evidence as specified in 5.1.8 

Id-rem-evidenceTypes-receivedFromNonREMSystem OBJECT IDENTIFIER ::= { id-rem-evidenceTypes 9 } -- 
OID for ReceivedFromNonREMSystem evidence as specified in 5.1.9 

REMEvidence : : = SEQUENCE { 

version Version, 

eventCode INTEGER OPTIONAL, 

eventReasons EventReasons OPTIONAL, 

evidenceldentifier UTF8String (SIZE (1..MAX)), 

evidencelssuerPolicylD [1] Policyldentif iers OPTIONAL, 

evidence I ssuerDe tails EntityDe tails, 

senderAuthenticationDetails [2] AuthenticationDetails OPTIONAL, 
recipientAuthenticationDetails [3] AuthenticationDetails OPTIONAL, 

eventTime GeneralizedTime, 

submissionTime GeneralizedTime OPTIONAL, 

replyTo UTF8String OPTIONAL, 

senderDetails EntityDetails, 
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recipientsDe tails EntityDetailsList , 

recipientsDelegatesDetails [4] RecipientsDelegatesDetails OPTIONAL, 

evidenceRefersToRecipient [5] INTEGER OPTIONAL, 

senderMessageDetails [6] MessageDetails OPTIONAL, 

notif icationDetails [7] MessageDetails OPTIONAL, 

forwardedToExternalSystem [8] UTFSString OPTIONAL, 

transactionLoglnformation [9] TransactionLogInf ormation OPTIONAL, 

extensions [10] Extensions OPTIONAL 
} 

Version ::= INTEGER { vl(l) } 

EventReasons ::= SEQUENCE SIZE (1..MAX) OF EventReason 

EventReason : : = SEQUENCE { 

code INTEGER, 

details UTFSString OPTIONAL 
} 

Policyldentifiers ::= SEQUENCE SIZE (1..MAX) OF Policyldentif ier 

Policyldentifier ::= CHOICE { 

old OBJECT IDENTIFIER, 

uri NonEmptyURI 
} 

EntityDetails ::= SEQUENCE { 

namesPostalAddresses [1] NamesPostalAddresses OPTIONAL, 

electronicAddress [2] ElectronicAddresses OPTIONAL, 

certif icateDetails [3] AuthorizedCertif icate OPTIONAL 

} 

NamesPostalAddresses ::= SEQUENCE SIZE (1..MAX) OF NamePostalAddress 

NamePostalAddress ::= SEQUENCE { 

entityName [1] EntityName OPTIONAL, 

postalAddress [2] PostalAddress OPTIONAL 
} 

EntityName ::= SEQUENCE { 

languageTag [1] LanguageTag OPTIONAL, 

namelnstance [2] UTFSString (SIZE (1..MAX)) 
} 

PostalAddress ::= SEQUENCE { 

languageTag LanguageTag, 

streetAddress MultiLineStreetAddress , 

locality UTFSString (SIZE (1..MAX)), 

stateOrProvince [1] UTFSString (SIZE (1..MAX)) OPTIONAL, 

postalCode UTFSString (SIZE (1..MAX)), 

count ryName Count ryCode 
} 

MultiLineStreetAddress ::= SEQUENCE SIZE (1..MAX) OF UTFSString (SIZE (1..MAX)) 

AuthenticationDetails ::= SEQUENCE { 

authenticationTime GeneralizedTime, 

authenticationMethod INTEGER, 

additionalDetails AdditionalDetails OPTIONAL 
} 

AdditionalDetails ::= SEQUENCE SIZE (1..MAX) OF Contentlnfo 
EntityDetailsList ::= SEQUENCE SIZE (1..MAX) OF EntityDetails 
RecipientsDelegatesDetails ::= SEQUENCE SIZE (1..MAX) OF RecipientsDelegateDetails 

RecipientsDelegateDetails ::= SEQUENCE { 

delegateDetails EntityDetails, 

delegatingRecipients List Of Integers 
} 

ListOflntegers ::= SEQUENCE SIZE (1..MAX) OF INTEGER 

MessageDetails ::= SEQUENCE { 

isNotification BOOLEAN OPTIONAL, 

messageSubject UTFSString, 

uaMessageldentif ier [1] UTFSString OPTIONAL, 
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messageldentif ierByREMMD 

hashAlgorithm 

hash 



[2] UTFSString, 
OBJECT IDENTIFIER OPTIONAL, 
BIT STRING OPTIONAL 



TransactionLoglnformation ::= SEQUENCE SIZE (1..MAX) OF UTFSString 
END 
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Annex F (normative): 

XML Schema for Evidence encoded in XIVIL 

<?xml version="l . 0" encoding="UTF-8" ?> 
<xs : schema targetNamespace="http : //uri . etsi . org/02640/vl#" 

xmlns :xades="http: //uri .etsi . org/0 1903 /vl . 3 . 2#" xmlns :ds="http: //www. w3 . org/2 00 0/0 9/xmldsig#" 
xmlns : tsl="http : //uri . etsi . org/02231/v2#" xmlns :xs="http : //www. w3 . org/2 l/XMLSchema" 
xmlns : rem="http: //uri .etsi .org/02640/vl#" elementFormDefault=" qualified" 
attributeFormDefault= "unqualified" > 

<xs : import namespace="http : //uri . etsi . org/01903/vl . 3 . 2#" 
schemaLocation="http://uri .etsi .org/0 1903 /vl .3 . 2/XAdES .xsd"/> 

<xs : import namespace="http : //uri . etsi . org/02231/v2#" 
schemaLocation=" . /draf t_tsl02231v020101xsd.xsd"/> 

<!--At the time of writing the present document no definitive URI is known for the xml schema of 
TS 102 231 v2 .1.1 --> 

<xs : import namespace="http : //www. w3 . org/2000/09/xmldsig#" 
schemaLocation= "http://www.w3 . org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema .xsd"/> 

<!-- List of evidence --> 

<xs : element name="SubmissionAcceptanceRejection" type="rem:REMEvidenceType"/> 

<xs : element name= " RelayREMMDAcceptanceRe j ect ion" type= " rem : REMEvidenceType " / > 

<xs : element name= " RelayREMMDFailure " type= " rem : REMEvidenceType " / > 

<xs : element name="DeliveryNonDeliveryToRecipient" type=" rem: REMEvidenceType "/> 

<xs : element name= "DownloadNonDownloadByRecipient " type= " rem : REMEvidenceType " / > 

<xs : element name= " RetrievalNonRet rievalByRecipient " type= " rem : REMEvidenceType " / > 

<xs : element name= " Accept anceRej ect ionByRecipient " type= " rem : REMEvidenceType " / > 

<xs : element name="RelayToNonREMSystem" type=" rem: REMEvidenceType" /> 

<xs : element name="ReceivedFromNonREMSystem" type=" rem: REMEvidenceType" /> 

<!-- EvidenceType definition --> 

<xs : complexType name= " REMEvidenceType " > 

<xs : sequence> 

<xs: element ref ="rem: EventCode" minOccurs="0"/> 

<xs: element ref ="rem: EventReasons" minOccurs="0"/> 

<xs: element name="Evidenceldentif ier" type="xs : string"/> 

<xs : element ref =" rem: EvidencelssuerPolicylD" minOccurs="0"/> 

<xs : element ref =" rem: EvidencelssuerDetails"/> 

<xs : element ref =" rem: SenderAuthenticationDetails" minOccurs=" 0"/> 

<xs : element ref ="rem:RecipientAuthenticationDetails" minOccurs=" 0"/> 

<xs: element name="EventTime" type="xs :dateTime"/> 

<xs: element name="SubmissionTime" type="xs :dateTime" minOccurs="0"/> 

<xs: element name="ReplyTo" type="xs : string" minOccurs=" 0"/> 

<xs : element ref =" rem: SenderDetails"/> 

<xs:element ref ="rem:RecipientsDetails" /> 

<xs : element ref = " rem : RecipientsDelegatesDetails " minOccurs= " " /> 

<xs:element name="EvidenceRef ersToRecipient " type="xs : integer" minOccurs="0"/> 

<xs: element ref ="rem: SenderMessageDetails" minOccurs=" 0" /> 

<xs: element ref ="rem:Notif icationMessageDetails" minOccurs="0" /> 

<xs: element name="ForwardedToExternalSystem" type="xs : string" minOccurs="0"/> 

<xs : element ref = " rem : Transact ionLoglnformat ion" minOccurs= " " / > 

<xs: element ref =" rem: Extensions" minOccurs="0"/> 

<xs: element ref ="ds : Signature" minOccurs=" 0"/> 

</xs : sequence> 

<xs : attribute name= "version" type="xs : string" use=" required" /> 

<xs :attribute name="ld" type="xs:lD" use="optional"/> 
</xs : complexType > 

<!-- EventCode --> 

<xs: element name=" EventCode" type="xs : anyURl"/> 

<!-- EventReasons --> 

<xs : element name= " EventReasons " type= " rem : EventReasonsType " / > 
<xs : complexType name= " EventReasonsType " > 
<xs : sequence> 

<xs: element ref ="rem: EventReason" maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType > 

<xs: element name=" EventReason" type="rem: EventReasonType"/> 
<xs : complexType name= " EventReasonType " > 
<xs : sequence> 

<xs: element name="Code" type="xs : anyURl"/> 

<xs: element name= "Details" type="xs : string" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType > 
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< ! - - EvidencelssuerPolicylD- - > 

<xs : element name="EvidenceIssuerPolicyID" type="rem: EvidenceIssuerPolicyIDType"/> 
<xs : complexType name="EvidenceIssuerPolicyIDType" > 
<xs : sequence> 

<xs: element name="PolicyID" type="xs : anyURI" maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType > 

<!-- EntityDetailsType --> 

<xs : element name="EvidenceIssuerDetails" type="rem: EntityDetailsType"/> 
<xs : complexType name= "EntityDetailsType" > 
<xs : sequence> 

<xs: element ref ="rem:NamesPostalAddresses" minOccurs="0"/> 
<xs: element ref ="tsl : ElectronicAddress" minOccurs="0"/> 
<xs:element ref ="rem: Certif icateDetails" minOccurs=" 0"/> 
</xs : sequence> 
</xs : complexType > 

<xs : element name= "NamesPostalAddresses " type= " rem : NamesPostalAddressListType " /> 
<xs : complexType name= "NamesPostalAddressListType " > 
<xs : sequence> 

<xs : element ref ="rem:NamePostalAddress" maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType > 

<xs : element name= "NamePostalAddress " type= " rem : NamePostalAddressType " / > 
<xs : complexType name= "NamePostalAddressType " > 
<xs : sequence> 

<xs:element ref ="rem: EntityName" minOccurs="0"/> 
<xs: element ref ="rem: PostalAddress" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType > 

<xs: element name =" EntityName" type="rem: EntityNameType"/> 
<xs : complexType name="EntityNameType" > 
<xs : sequence> 

<xs: element name="Name" type="tsl :NonEmptyString" maxOccurs= "unbounded" /> 
</xs : sequence> 

<xs : attribute ref ="xml : lang" use="optional"/> 
</xs : complexType > 

<xs : element name=" PostalAddress" type="rem: PostalAddressType"/> 
<xs : complexType name= " PostalAddressType " > 
<xs : sequence> 

<xs: element name="StreetAddress" type="tsl :NonEmptyString" maxOccurs= "unbounded" /> 
<xs: element name="Locality" type="tsl :NonEmptyString"/> 

<xs:element name="StateOrProvince" type="tsl :NonEmptyString" minOccurs="0"/> 
<xs: element name="PostalCode" type="tsl :NonEmptyString"/> 
<xs: element name=" Count ryName" type="tsl :NonEmptyString"/> 
</xs : sequence> 

<xs : attribute ref ="xml : lang" use="optional"/> 
</xs : complexType > 

<xs : element name="Certif icateDetails" type="rem: Certif icateDetailsType"/> 
<xs : complexType name="Certif icateDetailsType" > 
<xs : choice> 

<xs: element name="X509Certif icate" type="xs :base64Binary"/> 
<xs: element name="CertID" type="xades : CertIDType"/> 
<xs : element ref ="rem: CertIDAndSignature"/> 
</xs : choice> 
</xs : complexType > 

<xs : element name= " Cert IDAndSignature " type= " rem : Cert IDAndSignatureType " / > 
<xs : complexType name="CertIDAndSignatureType" > 
<xs : sequence> 

<xs : element name="IssuerSerial" type="xades :DigestAlgAndValueType"/> 
<xs : element name="tbsCertif icateDigestDetails" type="xades :DigestAlgAndValueType"/> 
<xs : element ref ="rem: CertSignatureDetails"/> 
</xs : sequence> 
</xs : complexType > 

<xs : element name="CertSignatureDetails" type="rem: CertSignatureDetailsType"/> 
<xs : complexType name="CertSignatureDetailsType" > 
<xs : sequence> 

<xs : element ref ="ds : SignatureMethod"/> 
<xs : element ref ="ds : SignatureValue"/> 
</xs : sequence> 
</xs : complexType > 

<!-- AuthenticationDetailsType --> 

<xs : element name="SenderAuthenticationDetails" type="rem: AuthenticationDetailsType"/> 
<xs : element name= "RecipientAuthenticationDetails " type= " rem : AuthenticationDetailsType " /> 
<xs : complexType name= "AuthenticationDetailsType " > 
<xs : sequence> 

<xs:element name="AuthenticationTime" type="xs :dateTime"/> 



ETSI 



83 ETSI TS 1 02 640-2 V2.1 .1 (201 0-01 ) 



<xs: element name="AuthenticationMethod" type="xs : anyURI"/> 
<xs: element name="AdditionalDetails" type="xades :AnyType" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType> 

<!-- EntityDetailsListType --> 

<xs : element name="SenderDetails" type="rem: EntityDetailsType"/> 

<xs : element name="RecipientsDetails" type="rem: EntityDetailsListType"/> 

<xs : complexType name= " EntityDetailsListType " > 

<xs : sequence> 

<xs: element name="EntityDetails" type="rem: EntityDetailsType" maxOccurs= "unbounded" /> 

</xs : sequence> 
</xs : complexType > 

<!-- RecipientsDelegatesDetailsType --> 

<xs : element name= " Recipient sDelegatesDe tails " type= " rem : Recipient sDelegatesType " /> 
<xs : complexType name= "Recipient sDelegatesType " > 
<xs : sequence maxOccurs= "unbounded" > 

<xs : element name= " DelegateDe tails " type= " rem : EntityDetailsType " /> 
<xs : element name= "Delegat ingRecipients " type= " rem : ListOf Integers " /> 
</xs : sequence> 
</xs : complexType > 
<xs : simpleType name= "ListOf Integers" > 

<xs : list itemType="xs : integer"/> 
</xs : simpleType > 

<xs : element name="SenderMessageDetails" type="rem:MessageDetailsType"/> 
<xs : element name="Notif icationMessageDetails" type="rem:MessageDetailsType"/> 
<xs : complexType name="MessageDetailsType" > 
<xs : sequence> 

<xs: element name="MessageSubject " type="xs : string" /> 

<xs: element name="UAMessageIdentif ier" type="xs : string" minOccurs=" 0"/> 
<xs : element name="MessageIdentif ierByREMMD" type="xs : string" /> 
<xs: element ref ="ds :DigestMethod" minOccurs="0"/> 
<xs:element ref ="ds :DigestValue" minOccurs="0"/> 
</xs : sequence> 

<xs rattribute name="isNotif ication" type="xs : boolean" use="required"/> 
</xs : complexType > 

<xs : element name=" Transact ionLoglnformat ion" type="rem:TransactionLogInf ormationType"/> 
<xs : complexType name="TransactionLogInf ormationType" > 

<xs : sequence> 

<xs : element ref =" rem: Transact ionLog" maxOccurs= "unbounded" /> 

</xs : sequence> 
</xs : complexType > 
<xs: element name=" Transact ionLog" type="xades : AnyType"/> 

<xs : element name=" Extensions" type="rem: ExtensionsListType"/> 
<xs : complexType name="ExtensionsListType" > 
<xs : sequence maxOccurs= "unbounded" > 

<xs : element ref =" rem: Extension" /> 
</xs : sequence> 
</xs : complexType > 

<xs: element name=" Extension" type="rem: ExtensionType"/> 
<xs : complexType name="ExtensionType" > 
<xs : complexContent> 

<xs : extension base="xades :AnyType"> 

<xs :attribute name="isCritical" type="xs : boolean" use="optional"/> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType > 
</xs : schema> 
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